Miroslav,
This is called a cut-through, and is not the default. The reason it isn’t the
default is because it propagates invalid frames (runts, run-ons, crc errors,
etc.) beyond the source port. Store and forward is the default. Cut-though
generally doesn’t work with port speed mismatch and
On Mon, Nov 21, 2016 at 10:28:26AM -0800, Denny Page wrote:
> The only layer we know the size of is the UDP layer. The Ethernet layer can
> have VLAN tag. Yes, it’s only 32 bits, but error is error. The IP layer may
> have option headers. This is rare with IPv4, but not with IPv6.
With TX
Miroslav,
There is no correction necessary. The speed change itself does not have any
impact because the transmission time is symmetrical.
Given host A on a 1Gb link and host B on a 100Mb link:
A -> Switch transmission time 754ns
Switch -> B transmission time 7540ns
Total time 8294ns
Miroslav,
We actually don’t know the length of the data at layer 2. We can’t even
guarantee the length at layer 3. Dispensing with layer numbers from now on.
We have three levels we have to concern ourselves with:
Ethernet
IP
UDP
The only layer we know the size of is the UDP layer. The
On Mon, Nov 21, 2016 at 09:38:36AM -0800, Denny Page wrote:
> Given host A on a 1Gb link and host B on a 100Mb link:
>
> A -> Switch transmission time 754ns
> Switch -> B transmission time 7540ns
> Total time 8294ns
As I understand it, modern switches don't wait until they have whole
> On Nov 21, 2016, at 10:59, Miroslav Lichvar wrote:
>
> On Mon, Nov 21, 2016 at 10:28:26AM -0800, Denny Page wrote:
>> The only layer we know the size of is the UDP layer. The Ethernet layer can
>> have VLAN tag. Yes, it’s only 32 bits, but error is error. The IP layer
On Mon, Nov 21, 2016 at 11:25:10AM -0800, Denny Page wrote:
> On Nov 21, 2016, at 10:59, Miroslav Lichvar wrote:
> > So, in order to make this as simple as possible, we could make an
> > assumption that received packets have the same format as transmitted
> > packets. At
I checked this. It appears to be completely symmetrical at the switch level.
For both the 1Gb and 100Mb ports, the delta I see for NTP packets is a very
consistent 912ns on a 1Gb mirror port. This is exactly as expected:
preamble: 56 bits
SFD: 8 bits
MAC dest: 48 bits
MAC src: 48 bits
I would not have expected this, and I haven’t dug into it, but looking at the
time to generate timestamps for pcap, I am seeing times of more than a
second(!). I am wondering what happens if we get to the point of sending the
next request before we have received the transmit timestamp for the
Miroslav,
Just to make sure I test correctly, would you mind creating a diff for a test
version for me? One that a can plug a hard coded number of nanoseconds
correction for just packet receive?
Thanks,
Denny
> On Nov 21, 2016, at 17:26, Denny Page wrote:
>
> I may hard
chrony-2.4.1 is now available. It's a bugfix release, which fixes a
crash with the smoothtime directive when used with the leaponly option
to perform a synchronised leap smear, processing of kernel timestamps
on non-Linux systems, and few other bugs.
The sources can be downloaded here:
11 matches
Mail list logo