Help wanted with Internet Packet Delay explanation

[foggycoder]

The following has been paraphrased slightly from the Vail website:

Your computer software transmits morse in the form of packets of data.
Each transmission (packet) consists of:
? Timestamp (milliseconds since 1 Jan 1970, 00:00:00 in Reykjavík), so your computer clock needs to be synchronised to an internet time server
? Transmission Duration (milliseconds)

Just like a radio repeater, a CW Repeater broadcasts everything it receives (Vail is a CW Repeater). When it receives those packets of morse data, it broadcasts them to whoever is listening, including your computer.

When your computer gets back the exact same thing it sent, it compares the Current Time to the Timestamp in the packet. This is the Round-Trip Time: the time it takes for a packet to get from your computer to the CW Repeater and back.

The Receive Delay is the difference between the time the packet was sent and the time it was received.

This is the point at which I start to get confused...

When your computer gets a packet it didn't send, it adds the Receive Delay to the Timestamp, and schedules to play the tones and silences in the packet at that time.

By adding the maximum Round-Trip Time to the longest recent Transmission Duration (the length of a dah, hopefully), your computer can make a guess about how much time needs to be added to a received Timestamp, in order to have it play back in the future at the time it comes in. This time is just an estimate. If you're communicating with somebody with a higher Round-Trip Time than you have, you'll need to raise your Receive Delay to account for it.

If a packet arrived so late that it can't be played in time, an error will occur. In technical terms: the Timestamp of the packet plus the Receive Delay is less than the Current Time. It can't be scheduled to play, because we can't go back in time.
This could be happening for three reasons:
1. You (the person getting the error) need a larger Receive Delay
2. The receiving computer's clock is in the future (running fast)
3. The sending computer's clock is in the past (running slow)


I'm guessing that each packet follows a different path across the internet and therefore the packet stream may arrive in a different order in which it was sent - hence the need for time parameters (to sort them back into transmission order).

I have two questions:
[list type=decimal]
[*]Can anyone provide a clearer explanation?
[*]Might this be an explanation of G0KZZ's experience of glitches and latency on CWCOM?
[/list]

 

[Ham4CW]

This is the point at which I start to get confused...

When your computer gets a packet it didn't send, it adds the Receive Delay to the Timestamp, and schedules to play the tones and silences in the packet at that time.

By adding the maximum Round-Trip Time to the longest recent Transmission Duration (the length of a dah, hopefully), your computer can make a guess about how much time needs to be added to a received Timestamp, in order to have it play back in the future at the time it comes in. This time is just an estimate. If you're communicating with somebody with a higher Round-Trip Time than you have, you'll need to raise your Receive Delay to account for it.

If a packet arrived so late that it can't be played in time, an error will occur. In technical terms: the Timestamp of the packet plus the Receive Delay is less than the Current Time. It can't be scheduled to play, because we can't go back in time.
This could be happening for three reasons:
1. You (the person getting the error) need a larger Receive Delay
2. The receiving computer's clock is in the future (running fast)
3. The sending computer's clock is in the past (running slow)

I'm guessing that each packet follows a different path across the internet and therefore the packet stream may arrive in a different order in which it was sent - hence the need for time parameters (to sort them back into transmission order).

I have two questions:
[list type=decimal]
[*]Can anyone provide a clearer explanation?
[*]Might this be an explanation of G0KZZ's experience of glitches and latency on CWCOM?
[/list]

I did add an answer to this earlier (done in a rush because of having to go out), but after just re-reading what had be quoted I could see that I had missed out on something. So this is 'Take 2'...

From what they're saying, the senders PC looks at the overall time taken by the packets sent out, to travel to the Vail server and back. That overall round trip time then becomes the Receive Delay.

Then, whatever time stamp is on an incoming packet that wasn't sent by the listeners PC has its playback time scheduled so as to be the transmit time plus the receive delay.

If the clocks are not synchronised to the nearest millisecond the whole thing breaks down rapidly!


As for the CW-Com glitches I keep experiencing, I think it may be down more to a local issue with my PCs, though there might possibly be some extra problems caused when CW-Com also has to deal with the incoming data from the CW-Com system.

Primarily though my money is still on an issue within the local machine, because I have found repeatedly that the transmit problems only seem to occur when I am using some form of plug in adapter for the key. Whether it is the more usual modified mouse adapter, or my 'experimental' modified keyboard controller adapter, the results are always the same, the side-tone latency and general keying go awry on a seemingly random basis, yet if I immediately swap over to using the down arrow on the keyboard it works fine.  If I then swap back to using a key plus adapter the problems return.

So to me this suggests it is a local issue within the machine, but, I've also found that if the PC is off-line and I'm only running CW-Com for sending practice verification, it does not glitch at all. Possibly then, it is not the propagation delay causing the keying issue while online, but the fact that CW-Com has much more to deal with, since essentially it would be running semi duplex at that point, with constant switching between TX and RX.

I did try increasing the changeover delay to its maximum setting, bit it did not help one bit. However, I don't believe it is a 'real' changeover as would be seen in a transceiver, it looks instead more like an extra delay is added to the playback time, but in reality I think the 'receiver' is actually still running, and CW-Com is just buffering more received packets.

Anyway, wrong thread alert!

73, Mark...