Challenge Next multi-user event in Moon orbit... stay tuned

Boxx

Mars Addict
Donator
Joined
Nov 15, 2009
Messages
69
Reaction score
50
Points
18
Location
Paris Area
To be frank, I think the event yesterday was a half-success only: there were 7 of us connected but only 3 visible, too bad!! But it's ok, as it is part of the experiment as well. Lessons learned:
  • Stack of add-ons + Connection process = too heavy procedure :(
  • Training (for beginners) is desirable in advance: for setup and piloting
  • The Twitch page helped to understand what was going on. For sure that's a good addition
  • The server and its local client (ORBIX) ran well (we doubled the CPU and the RAM just on Friday, the streaming appears too demanding)
  • It is a place for fun encounters, even before the event :)
  • One can move someone else's vessel: the after-party showed the pilot Jankzi playing a "Smack!" with ORBIX :)
Here are some links for those who want to follow this experiment:
The next event should be a "butterflies flight" with a vessel to be selected among 2 possible, then taking off by hoovering from a Moon station and starting a Low Moon Orbit as a swarm (not too ambitious?)

Jankzi's Smack! to ORBIX:
 
Last edited by a moderator:

Boxx

Mars Addict
Donator
Joined
Nov 15, 2009
Messages
69
Reaction score
50
Points
18
Location
Paris Area
@Face :
  • The NTP tag has one or many Server children tags.
  • A Server tag has attributes "Address", "Misses", "Delay", "Alarm". "Address" is the SNTP server host name. "Misses" is the amount of allowed SNTP call misses before the server is suspended. Suspension means, that the server is not taken into account while randomly choosing servers for SNTP calls. The "Delay" means how many suspended "hits" the random algorithm must do on the server before it is reactivated again. It is a multiplier, meaning that value of "Delay" times value of "Misses" is the exact amount of suspended "hits". "Alarm" at last means at which point the server is permanently suspended from being taken into account. Again, this is a multiplier, meaning that value of "Alarm" times value of "Delay" is the exact amount of misses allowed for the permanent suspension taking place.
  • The Timing tag has attributes "Transmitter", "GarbageCollector", "SNTP", and "Resync".
I'm coming back to these settings.

Apparently my OS (on a virtual machine) needs SNTP. I understand that I could as well select multiple "possible" sntp servers... and why not, indeed. Then, the more the better, isn't it?

Timing tag is possible on both Client and Server sides. What does it mean for each one?!, for instance if "Transmitter" contradicts/collides between server and client(s)?

Nevertheless, I am testing again the no-SNTP configuration: then all non-dashed tags and attributes (in documentation) should be given, shouldn't they?
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,371
Reaction score
542
Points
153
Location
Vienna
@Face :

I'm coming back to these settings.

Apparently my OS (on a virtual machine) needs SNTP. I understand that I could as well select multiple "possible" sntp servers... and why not, indeed. Then, the more the better, isn't it?

Timing tag is possible on both Client and Server sides. What does it mean for each one?!, for instance if "Transmitter" contradicts/collides between server and client(s)?

Nevertheless, I am testing again the no-SNTP configuration: then all non-dashed tags and attributes (in documentation) should be given, shouldn't they?
Your setup does not need SNTP. What is important is that clients are synchronized to the server clock, but not that the server clock is synchronized to UTC. It is necessary that both client and server configurations omit the SNTP tag. If the server syncs to UTC but the clients don't, it is not so problematic, but the server could get a "hickup" from stalled SNTP server calls (e.g. if the single SNTP server you configured is down or blocks you due to DDOS measures). If one or more clients sync to UTC, but the server doesn't, they won't sync at all. Best thing is to leave out the SNTP on both sides.

Transmitter timing on both sides is how long the sender loop waits before it does another round. Nothing more. Since the protocol is not a handshaking one, but more like a streaming thing, differences in the values don't matter beyond the immediate effects of a fast or slow transmitter. Probably the combination of transmitter and garbage-collector timing is more important: if e.g. the server has a long transmission interval of say 1 minute, but the client garbage-collector is set to 1 second, you will only see remote vessels for one second, then they are gone for almost a minute again.

Therefore I'd recommend to stay with the values that come with the distribution. On both sides. Those are:
  • no SNTP tag in client config, only transmitter timing configured to 200ms
  • no SNTP tag in server config, transmitter timing set to 200ms. The SNTP call timing is set to 2s there, as well as the resync interval set to 1m, but this has no effect.
BTW: you can experiment with timings during the session as well, by means of using the in-chat commands that are escaped with "%" on default settings. Entering "%help" in the chat window will list you the available commands. That's only available in clients, of course. No such thing on the server side.
 

steph

Well-known member
Joined
Mar 22, 2008
Messages
1,214
Reaction score
559
Points
113
Location
Vendee, France
I probably won't partake anytime soon, I still need to polish my orbital rendezvous techniques to be able to do it without abusing the fast forward feature, but how much bandwith would be needed for a usual play session? Say, could I connect via a mobile hotspot etc?
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,371
Reaction score
542
Points
153
Location
Vienna
I probably won't partake anytime soon, I still need to polish my orbital rendezvous techniques to be able to do it without abusing the fast forward feature, but how much bandwith would be needed for a usual play session? Say, could I connect via a mobile hotspot etc?
OMP is lightweight on bandwidth on the client side, especially if the session has few users. You have one TCP stream and one UDP transceiver. I guess with 10 users it would work just as well over 56k modems.
 

Boxx

Mars Addict
Donator
Joined
Nov 15, 2009
Messages
69
Reaction score
50
Points
18
Location
Paris Area
Therefore I'd recommend to stay with the values that come with the distribution. On both sides. Those are:
  • no SNTP tag in client config, only transmitter timing configured to 200ms
  • no SNTP tag in server config, transmitter timing set to 200ms. The SNTP call timing is set to 2s there, as well as the resync interval set to 1m, but this has no effect.
These settings have been deployed for 2 days without failure, so we can indeed consider them stable. Thank you for your support.

BTW: you can experiment with timings during the session as well, by means of using the in-chat commands that are escaped with "%" on default settings. Entering "%help" in the chat window will list you the available commands. That's only available in clients, of course. No such thing on the server side.
Indeed, and quiet advanced commands.... to be explored step by step :)

Also, I could see on ORBIX' log that multiple short connections from many places were attempted (UK, Germany, US / several locations, Slovakia, Indian ocean...). These connections were very short, i.e. 1 to a few seconds up to 90s, without succeeding at showing a "vessel" with its Tail-ID. Does it mean that users try to connect and fail? please report if so. Or are these only attempts by some bots.....

(attached = v2-2, includes modified OMPClient.xml)
 

Attachments

  • OrbiterX_ZIP_v2-2.zip
    2.6 MB · Views: 1
Last edited:

Boxx

Mars Addict
Donator
Joined
Nov 15, 2009
Messages
69
Reaction score
50
Points
18
Location
Paris Area
I probably won't partake anytime soon, I still need to polish my orbital rendezvous techniques to be able to do it without abusing the fast forward feature, but how much bandwith would be needed for a usual play session? Say, could I connect via a mobile hotspot etc?
On our side, I want to prepare a "simple" lunar space meeting, then we hope to be able to deploy an "OMP" version with a save/restore function between client and server, to allow users to keep their vessel from a connection to the next. So we still have a little work ahead...

In the meantime, the use of OMP behind a low bandwidth connection is worth reporting. ORBIX can serve as a target: if it appears stable in your client, it means that your own vessel likely appears to be stable by others.


Or if ORBIX crashes, you can see it on Twitch... and no drama with that, actually you can try a Smack! (docking) with ORBIX, it's fun and if ORBIX client crashes I will reset it a bit later.
 
Top