As MichaelT pointed out you need to be clear on metrics that you are trying to measure and the ones that make sense to you. Some common metrics when it comes to measuring network performance are
- Throughput.
- Latency.
- Server and client response time.
In my opinion just measuring RTT is not sufficient to measure performance of routing because the RTT is influenced by lots of external factors like link performance not necessarily routing performance also your RTT for the same link and same router may be different over number of trial. Throughput on the other hand will give you fairly better idea over how your network performs(keeping the network very minimal is the key to get exact routing throughput).
To answer your second part of the question:
Any homegrown system to measure traffic performance will require a bit of an effort and time and may not be able to provide accurate numbers, if you have budget try looking for commercial solutions like Ixia, Spirent or shenick.
If you do not have the budget I cannot think of a single tool that will help you get all the metrics but can integrate different tools to a wholesome system.
I have found pmacct to be very powerful and flexible to account for traffic,It collects different metrics about the data flows,The issue with this is it also includes layer 7 data so your numbers will be a bit skewed on the lower side(routing throughput will be way higher than the actual application throughput).
But if you are not really concerned about publishing the numbers to your customers this will help you get a fairly decent baseline to compare against different routing protocols.
A much simpler solution will be to use bwm-ng which will display the traffic rate on an interface.It gives only throughput data nothing else, at least nothing that I know of.
Generating traffic to push to the limit of the link will be a challenge you will probably need a fairly huge machine(like a Dell 8000 series) to pump around a gig of data.There are lots of open source traffic generation tools like curl-loader, scapy etc.. which will help you generate traffic.
Depends on if you're talking about peer-to-peer, client/server with the users running the server, or client/server with a data center running the server. Only in the latter-most case is the internet really fast and reliable. Your users' computers are not guaranteed to be fast, and certainly won't be reliable.
UDP allows you greater control over the sort of TCP-like implementation you're making. It gives you greater flexibility to execute packets out of order, discard packets that you consider unnecessary while retrying packets you consider important, that sort of thing. But this should only be done if needed and if you have the necessary expertise.
If you can do without that flexibility, TCP works well enough and saves you a whole lot of time. Even professional studios (like one I worked at) use TCP if they don't absolutely need UDP, and they have people dedicated to network programming.
Best Answer
I think it is definitely not OK to synchornize the clock in the system. User does not expect you to touch the system settings and many systems won't even let you to.
All you need is to have a correlation to convert timestamp from one side's clock to the other side's clock. On the other hand you need this correlation to be rather precise, say at least to a hundredth of a second, if you want to use it for predicting player positions. System clock won't ever be this well correlated between random machines. So you should establish the correlation yourself, using some variation on the NTP theme, probably embedded in your other messages to conserve network bandwidth.
The basic idea might be that with each packet you sent out timestamp you sent it and sequence number of and timestamp when you received last packet from the other side. From this you calculate the roundtrip: For example if packet Q says it was sent at 1000 and packet P was received at 500, than given you sent packet P at 0 and are receiving Q at 800, the round-trip is (800 - 0) - (1000 - 500) = 300. There is no way to know the assymetry, so you just assume the packet takes half (150) ticks in either direction. And that remote timestamp is ahead of local by 1000 - (800 - 150) = 350 ticks. The round-trip will vary. If you assume the clock are reasonably precise, you should use a long-term average of the correlation.
Note, that you don't want to use system clock for the clock either. They may get resynchronized midway, throwing you off track. You should use
clock(CLOCK_MONOTONIC)on Unix orGetTickCounton Windows (not sure how those APIs are wrapped in Java or Python right now).Note: The
SO_TIMESTAMPsocket option (see socket(7) mentioned by ott-- in comment on the question) would be useful for separating out the effect of latency of the event loop that receives the packets. Whether it's worth the effort depends on just how good precision you need.