I get how to calculate ping - current time minus the time stamp of the packet - but how do I create a time stamp in the first place? What synchronized concept of time can I use? Note: I use .NET 2.0.
It could be as simple as when you issue your ping request (I will explain this in more detail in a moment), you make note of the current time, and then, when the server/client responds with a pong, you make note of the time again. Subtracting the pong time from the ping time gives you the amount of time for the communication to go between the two applications.
Wikipedia describes ping in the following way:
In multiplayer online video games, MMOs, MMORPGs, MMOFPSs and FPSs ping (not to be confused with frames per second) refers to the network latency between a player's computer (client), and either the game server or another client (i.e. peer). This could be reported quantitatively as an average time in milliseconds... Rather than using the traditional ICMP echo request and reply packets to determine ping times, game programmers often instead build their own latency detection into existing game packets
What I like to do, is when I make a client and a server, I always write in a simple 'ping/pong' command. In short, a ping request is made by one application, when the other application receives it, and sends back a pong confirmation command. This is good for debugging, but for actual development and depending on the game, I usually piggy back this with a heart beat to make sure everything is running as it should. Hope that helps!
Related
We have a system with two micro-controllers and we are developing a simulation environment. In the real system the micro-controllers communicate trough UARTs sending small data back and forth all the time every millisecond (asking for variable values, sending commands, etc.).
In the simulation each micro-controller is a different application and we must find a way to communicate them. I have tried TCP/IP before but I notice from time to time there are very long time delays - for example it works ok and after 20 messages there is a second delay. I assume this is because TCP/IP is not designed to send small packets of ~10 bytes of data every millisecond. I have found some information about the issue but nothing conclusive on how to avoid the problem.
I was wondering if NamedPipes will work better. Will there be a huge performance hit when using NamedPipes to communicate back and forth ~10 bytes of data every ms? Should we look into another alternative? In the past the company has used virtual serial ports but that requires special third-party software and is too cumbersome to set up.
Sorry for my bad english first.
I'm currently working on an Arduino project which is really simple.
I'm working on an attendance logger for my school to know how much time students are spending studying.
The RFID Reader part is working fine. When a tag is detected, I'm storing the value and the time in a SD Card.
Every hour, my system have to send the logs to a web server to store it in a database and here come my problem. I'm struggling with the ethernet part.
Indeed, when I'm performing a HTTP Request, my sketch is "blocked" and students can't use the system anymore.
It's a real big problem, because if there are like 200 lines in my logs, sending those throught a request, one by one, will take really long.
I'm already aware of using millis() to use "multi-tasking".
I have absolutly no idea about how to send requests without "blocking" my sketch.. I'm not looking for someone to write my sketch. I just want to know if there is a way to avoid the "blocking" effect of the ethernet shield when I'm performing a request.
Thanks for your help.
Even if you send one by one, you dont have control over the server side. you have no gurantee that the server will Always response within a certain timeframe.
if your system is very busy, then this may not be your perfect solution.
on other hand, just a thought though, (I dont have personal experience with ethernet shield.)
you could send data serially from first arduino to second ardiuno, individually, every time RFID is detected. This should not take much time compare to the time to send 100 lines of logs. Now, one by one, second ardiuno can save these data in its memory until it is finally sent to server.
now when second arduino is busy sending data to server, we can collect some those RFID reading in first arduino's memory, and pass to, when the things with server is done.
to check if second arduino is bg, we could set a pin high in second arduino until the server part is done.
but still, I dont see why do you have to send it every one hour. I am asuming you have your reason.
If you still want to save some time, the make a parallel data transfer between two arduino, instead of serially.
We are trying to optimize our ASP.NET MVC app and get a big time difference between our server side logs and client side delay.
When refresh the page in Chrome in Timeline it shows 4.47s:
As I understand from the picture, the time for server side code execution should be 3.34s, but in our server logs we have the following:
Begin Request 15:41:52.421
End Request 15:41:53.218
Pre Send Request Headers 15:41:53.218
Pre Send Request Content 15:41:53.218
So, according to server side logs code execution took only 797ms in total.
It does not happen all the time and very often the Chrome timeline shows times very close to server logs. But sometimes we have this couple of seconds delay.
Where could this delay come from?
There is lot of stuff that can affect the time sporadically to such an extent, even though addition of almost three seconds is sort of excessive for this scenario. Since you don't mention much about how is your network set up, what operating system u use etc,
I'll try to sum up a list of what comes to my mind when dealing with this sort of a delay, sorted by probability.
The main problem here is the Waiting part of the total time there you should concentrate your detective talent.
Please note that the answer is very general since the question says virtually nothing about configuration of the server, client computer or the network (if any) between them. Since you say the delay is not present all the time, there are one or more moving targets you need to aim at.
Antivirus
If you have an internet shield or similarly named component, it is not uncommon that the antivirus can seemingly randomly delay some connections while leaving other virtually untouched. For the browser this is transparent (it's just a delay, whatever may have caused it), hence the Waiting.
Network issue
Especially if you are connected through a wireless network or poorly configured wired network, a few seconds delay may occur even though the label on the network device says TurboSpeedTM.
Server side issue
Server may be overloaded with previous requests in a manner not covered by your in-application timer, since there are many steps the server performs before and after your script is executed.
Client OS issue
Just like the antivirus, the OS can delay your packets virtually randomly for various reasons.
When hunting down such issue, I would recommend trying to perform the query on the server itself and compare resulting times, try as may combinations of network setup and operation systems as possible, prefer well planned network environments to those with many unknown or external factors (read wireless) and make use of some packet sniffing software (like wireshark) to check whether the browser doesn't lie. And that would be just the start of it :)
I'm writing a multiplayer Flash game, and the server is written in Python and it updates 25 times a second. Every update, if a player is moving, the server sends out TCP messages containing the new positions of that player. Running locally, everything was lovely, but I've recently pushed the code to a higher-spec deployment server (with a 100Mbps pipe connection) to test how it plays.
I'm glad I did, because what I am noticing is that these update messages are bunching up during sending and they arrive in six's. Testing locally, the messages were arriving at 1/25th of a second intervals, and so player movement was very smooth, now it really isn't.
If you had this same issue, what are the things you would look at, experiment with, in order to find a solution?
You can try disabling Nagle's algorithm to make sure segments are sent straight away. However, given your requirements, I wonder if UDP isn't a better match.
We can use Ping command to measure responsetime for network.But is it the pure responsetime of network or does it include processing time ?
Kindly help to resolve this issue.
"The network" wouldn't exist without processing time being spent. Nothing happens for free, routing, TTL handling, and upholding all the protocols of course requires processing time on all nodes touched by a given path through the network.
And in the case of 'ping', then yes there is some processing required by the target machine's IP stack to detect the incoming request, and create and send the proper response. But that time is probably more or less constant (assuming constant background load), and often very small when compared to the pure transmission delays.
You can test this out by pinging localhost, then hosts on a local network, and comparing the differences in response times, assuming your ping implementation reports them with high enough precision.
That does indeed include processing time. Otherwise you'd be pretty close to the speed of light.
If your question is if the processing time on the pinged host is included too, yes it is but that should be only a small amount.
ping is so simple that processing time is very low compared to network time (provided you don't check a LAN with 1Gb Ethernet). Anyway, processing time is to be taken into account because actual network traffic also needs time to be processed.