It seems that Export() is currently operating at a minimum of a 1/10ths second delay.
When using Export to transfer data between two servers, this translates to a 200ms minimum ping, before figuring in network latency between the two server endpoints.
Given some testing, I wound up with a 600ms ping with Export() on a server where I had roughly 67ms ping between my seeker and their server.
So, that said, Lummox indicates that this is due to Nagles' algorithm being active, for which he claims there's no reason to have around anymore.
ID:1405894
 Oct 25 2013, 11:07 am
|
|||||||
Resolved
| |||||||
|
Oct 29 2013, 10:23 am
|
|
Lummox JR
   |
Lummox JR resolved issue with message:
|
How much faster is it?
| |
I'll run my test environment once 1217 hits a release candidate.
MDC and Lige should be quite good subjects with which to test my client/server messaging system. Will post results here after. Theoretically, though, it should be relatively instantaneous. As I understand it, Nagles' algorithm just sort of waits for messages to queue up until either the backlog has achieved a certain threshold, or a minimum time has elapsed. It appeared, during my tests, that this timer was running at a minimum of 100ms, resulting in absolutely minimum ping-pongs of 200ms. If Nagles' algorithm is off and my understanding is correct, it should fire the message immediately from the sender, it will be retrieved by the receiver, and await processing until the next server tick (Theoretically a maximum threshold of world.tick_lag seconds), be processed once the scheduler runs the Topic() command, and immediately fire back, repeating the process for acknowledgement. I'll have to test, but I'm hoping we'll see results in the sub-90ms time frames, which is, as far as networked games are concerned, as close to instantaneous as it can get. | |
yeah, Nagle's is used to prevent a ton of small packets with more bandwidth used by overhead than actual throughput.
I'd personally rather see Nagle's remain on, but have its timeout period set to the world's tick lag - sending packets any faster won't help much if they just sit at the recipient waiting to be processed. Of course, this would only be if the savings in bandwidth make it worthwhile. | |
 Seems that I'm not getting any kind of speed improvement at all in 1217. I'm still capped to a minimum of 2/10ths of a second. I'm measuring my speed with world.time, and it just doesn't seem to be moving faster. I get an average ping of 192ms round-trip. This setup was hosted on my local machine. I'll be testing over a network and updating here in a second. | |
If anybody else is interested in double-checking my approach to testing this feature:
http://files.byondhome.com/Ter13/ServClient_src.zip http://files.byondhome.com/Ter13/ClientServ_src.zip I've tested the client at 100fps and the client at 60fps, as well as 60fps on server, 30fps on client, and 30fps on both. It appears that the minimum latency for export is still somewhere near 100ms on a local machine. | |
Well, it did certainly improve, but we're not down to acceptable thresholds quite yet.
These are the results my later test over a network in which I've got an 83ms roundtrip ping with the ClientServ graciously hosted by MDC for remote server testing:  This time, we're down from roughly 10x to 5x latency of the built-in layer. However, given my calculations, at 30fps on the client and 30fps on the server, We should be seeing a minimum additional latency of 33ms, and a maximum additional latency of roughly 90ms. If the ping between client and server is averaging 83ms ping, and the scheduler adds a possible upper threshold of 90ms delay, the maximal latency we should be seeing between the endpoints is roughly 173ms round trip. Honestly, however, I'm uncertain of why Nagles' algorithm should have had to have been turned off, because it seems to me that the bottleneck would have rested with a piece of code still being somehow limited to 1/10th second ticks somewhere underneath the VM in how BYOND communicates Import/Export/Topic data. However, that said, we're seeing values around 500%-600% over the latency that we should be expecting. If we can get latency down to around 60-90ms one-way, I'd say that would be a very useful step forward for freeing up BYOND games from the built-in networking implementation. | |
Ter13 wrote:
Honestly, however, I'm uncertain of why Nagles' algorithm should have had to have been turned off, because it seems to me that the bottleneck would have rested with a piece of code still being somehow limited to 1/10th second ticks somewhere underneath the VM in how BYOND communicates Import/Export/Topic data. That's most definitely not the case. The client and server will both tick at the rate specified by tick_lag. But networking should be able to go a little faster than that (threading considerations aside), since with Nagle's algorithm off on both sides, it'll send and receive data right away rather than waiting a certain time to respond. We're also not using queuing as we do in normal server-to-client messages. Whatever the problem is, it's not related to BYOND's default tick speed. | |
Okay, well, I'm sorry to be a bother here, but I'm almost certain there's an issue here. We did indeed see minor speed boosts, but something else is definitely going on. Unless of course, something in my tests is just plain off. The source of both the client and server I have written are included in the posts above.
| |
I tried a similar, self-written thing, as well as Ter13's examples, and got th same kind of behaviour. Each world.Export() seemed to result in a 100 ms delay before the world/Topic() got called.
So doing a ping-pong between two servers locally took 200 ms. Ping-pong form/to the same server was 100 ms. | |
Bumpity? I don't have any additional information but this is something that I'd definitely like to see resolved.
| |
Can we get an update on what's been going on with this, or why Export() isn't more responsive?
This makes SQL interaction and cross-server communication somewhat problematic. | |
Do we have any comments or updates about this? We have provided a project that shows its not performing as expected.
| |
Bumping this topic for justice and good measure. Export is still operating at an apparent minimum of 100ms delay.
| |
Agreed that improving this would be a big advantage so we'll take another look.
| |
Tom wrote:
Agreed that improving this would be a big advantage so we'll take another look. Awesome, thanks! | |
I believe, while these trackers are being updated, that the status of this should be changed to 'Unresolved'.
| |
Unfortunately, we can't change resolved requests/bug reports that have a specific version tied to them, as they pretty thoroughly mess up the version history autobuilds.
| |
This will be beautiful if it gets up to par :D
| |