As the first test revealed that most UDP packets make it safely at least when sent 1 second apart, I decided that the next week-long test should run with a substantially smaller delay: 0.01 seconds between each 2 packets. Moreover, I've changed the sender to simply send 10000 packets at each run, alternating between 1472 and 1470 octets in size. The focus on those 2 sizes reflects the fact that ALL packets are either 14721 or 14702 octets long in the newest version of Eulora's communication protocol. Here's the summary of the data I collected:
|Received:||2134569 (99.74%)||2139788 (99.99%)|
|1470-size received:||1067322 (99.75%)||1069901 (99.99%)|
|1472-size received:||1067247 (99.74%)||1069887 (99.99%)|
From the above, it would seem that even 0.01 delay between any two packets being sent is not causing any problem at all - at least not for the sizes considered4. If anything, the % of received packets increased slightly compared to the previous test. Of the packets that made it to the other side, none were mangled, hence no errors received5. Unsurprising perhaps, the 2 octets difference in size between the 2 types of packets does not seem to have the slightest impact on % of packets that make it to the other side - the route itself is likely to be more important in this respect.
The timings remain iffier to investigate as I did not change the tester specifically for this. Applying the same correction as in the previous test (i.e. calculating first the difference between the logged local times and then simply adjusting so that the minimum difference is 0) yields again the same stats on both sides (if slightly different values than during the last test):
|Data||Min||1st Q||Median||Mean||3rd Q||Max|
|UK -> UY||0||7||13||13.09||20||27|
|UY -> UK||0||7||13||13.19||20||27|
As before, I would not suggest taking the above timings for anything really. The only thing that can perhaps be said is that packets don't seem to take all that much to arrive at their destination at least on those routes. This is of course no guarantee at all, just a limited observation of this particular data set.
Serpent encrypted packets that are meant for most communications in Eulora. ↩
RSA encrypted packets that are meant only for new accounts in Eulora. ↩
I've ran this for almost 9 days so more than the previous 1 week for the first test. ↩
Arguably larger sizes that would get fragmented on the way might have higher chances of becoming lost. ↩
There was however one spam packet received by the node in UY from an entirely unrelated IP but I removed that before making the summary above since it has nothing to do with the test itself. Also, the fact that one will receive spam is not exactly news otherwise so there isn't much to say about it at this moment. ↩
Comments feed: RSS 2.0