We haven't been able to reproduce this, but there should be a fix in the latest driver and a spec update is forthcoming.
Thanks. Todd Fujinaka Software Application Engineer Networking Division (ND) Intel Corporation [email protected] (503) 712-4565 -----Original Message----- From: Fujinaka, Todd [mailto:[email protected]] Sent: Thursday, December 05, 2013 11:01 AM To: Julien Houles; [email protected] Subject: Re: [E1000-devel] Problem with SYSTIMH register readout We're going to try to reproduce this locally. We may or may not have the same motherboard so can you make sure you have the latest BIOS? Todd Fujinaka Software Application Engineer Networking Division (ND) Intel Corporation [email protected] (503) 712-4565 From: Julien Houles [mailto:[email protected]] Sent: Friday, November 22, 2013 1:24 PM To: Fujinaka, Todd; [email protected] Subject: Re: [E1000-devel] Problem with SYSTIMH register readout Thank you for your answer. In fact, I only use phc2sys in these examples (there is no call to settime because ptp4l is not running and the phc clock is master). The slave clock is CLOCK_REALTIME and the master clock is the phc clock. The phenomenon I talk about occurs in only one readout among the five consecutive ones made at each phc2sys interation. Each readout takes about 5 microseconds. If I look at the phc time of the readout before the problematical readout and the one after, I get a difference of 10 microseconds. There is only one read in the middle which is false. Unfortunately, I don't have the traces containing the system time anymore. I'll send them to you when I'll make measurements, I'll add traces in the settime function too. Contrary to what I said, the problem doesn't seem to affect only SYSTIMH, I noticed irregularities in the SYSTIML register too. More details : driver version : e1000e-2.5.4 boards : jetway NF9I-2550 (atom processor) + daughter board with four 82574l kernel : 3.11.6-200 linuxptp version 1.3 Le Vendredi 22 novembre 2013 19h21, "Fujinaka, Todd" <[email protected]<mailto:[email protected]>> a écrit : I think we need more details before we can proceed. There's no indication of what the system time was at any given point, no log from what the link partner was doing, no statement about whether we were the clock master or slave, etc. We would recommend swapping the configuration around and make the link partner the slave (there's a ptp4l option for doing this) for an initial test. We generally expect SYSTIM to increment, but there is nothing explicitly enforcing that. If something causes the slave clock to be too far ahead of the master, it's valid for ptp4l to hard reset our clock back to a closer time. If you need further help, it would be nice to see ftrace/debug statements to show what functions are getting called when this happens to confirm if we're getting the call to settime or not. Thanks Todd Fujinaka Software Application Engineer Networking Division (ND) Intel Corporation [email protected]<mailto:[email protected]> (503) 712-4565 -----Original Message----- From: Julien Houles [mailto:[email protected]<mailto:[email protected]>] Sent: Thursday, November 21, 2013 5:59 AM To: [email protected]<mailto:[email protected]> Subject: [E1000-devel] Problem with SYSTIMH register readout Hello, When I use linuxptp with phc2sys or ptp4l, after an variable amount of time, I've got an offset explosion. I use an Intel 82574l chip. I investigated in the code and I found out that the problem comes from the readout of the SYSTIMH register (ine1000e_cyclecounter_read function). The value read in this register should always increase (or at least be equal to the last value read). But sometimes, the value read is smaller that the last one ! Here are three examples : ex 1 : er32(SYSTIMH) -> 0x00D3842C er32(SYSTIML)->0x0C600000 er32(SYSTIMH) -> 0x00D3842D er32(SYSTIML)->0x79600000 er32(SYSTIMH) -> 0x00D3842E er32(SYSTIML)->0x54200000 er32(SYSTIMH) -> 0x00D3842F er32(SYSTIML)->0x29E00000 er32(SYSTIMH) -> 0x00D38420 er32(SYSTIML)->0xFFA00000 Problem ! er32(SYSTIMH) -> 0x00D39326 er32(SYSTIML)->0x16C00000 er32(SYSTIMH) -> 0x00D39327 er32(SYSTIML)->0x5EE00000 er32(SYSTIMH) -> 0x00D39328 er32(SYSTIML)->0x3AE00000 er32(SYSTIMH) -> 0x00D39329 er32(SYSTIML)->0x10000000 er32(SYSTIMH) -> 0x00D39329 er32(SYSTIML)->0xE4800000 ex 2 : er32(SYSTIMH) -> 0x0799808E er32(SYSTIML)->0x07A00000 er32(SYSTIMH) -> 0x0799808D er32(SYSTIML)->0x7A400000 er32(SYSTIMH) -> 0x0799808C er32(SYSTIML)->0x55A00000 er32(SYSTIMH) -> 0x0799808F er32(SYSTIML)->0x2AC00000 er32(SYSTIMH) -> 0x07998089 er32(SYSTIML)->0xFFE00000 Problem ! er32(SYSTIMH) -> 0x07998F86 er32(SYSTIML)->0x1DE00000 er32(SYSTIMH) -> 0x07998F87 er32(SYSTIML)->0x6F600000 er32(SYSTIMH) -> 0x07998F88 er32(SYSTIML)->0x4DE00000 er32(SYSTIMH) -> 0x07998F89 er32(SYSTIML)->0x23A00000 er32(SYSTIMH) -> 0x07998F89 er32(SYSTIML)->0xF8C00000 ex 3 : er32(SYSTIMH) -> 0x0D8854EB er32(SYSTIML)->0x4A800000 er32(SYSTIMH) -> 0x0D8863E1 er32(SYSTIML)->0xD5E00000 er32(SYSTIMH) -> 0x0D8863E3 er32(SYSTIML)->0x23A00000 er32(SYSTIMH) -> 0x0D8863E1 er32(SYSTIML)->0xFFA00000 Problem ! er32(SYSTIMH) -> 0x0D8863E4 er32(SYSTIML)->0xD6000000 er32(SYSTIMH) -> 0x0D8863E5 er32(SYSTIML)->0xA9400000 er32(SYSTIMH) -> 0x0D8872DD er32(SYSTIML)->0x8F800000 Does someone know what could be the origin of that ? It seems that it only affects the 4 first bits of the register. The value read after the iteration when the problem occurs seems to be good (regarding to the value before the bad iteration) if I consider the average interval between two readings (five consecutive readings). So, the problem doesn't seem to come from the counter but the reading of it. By the way, I've got an other problem with phc2sys which could come from the driver or the ethernet chip : The offset between the phc and CLOCK_REALTIME can be good (less than a 100 ns) but a few days after, without any identified reason, it can be very bad (several microseconds) et be good again after a while. All that with the same hardware, software and similar environmental conditions ! Any idea ? Thank you, Julien. ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
