linuxptp-users Mailing List for linuxptp (Page 135)
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users — Open discussion on using the linuxptp software.
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
(10) |
Mar
(47) |
Apr
|
May
(26) |
Jun
(10) |
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
(20) |
Nov
(14) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(6) |
Feb
(18) |
Mar
(27) |
Apr
(57) |
May
(32) |
Jun
(21) |
Jul
(79) |
Aug
(108) |
Sep
(13) |
Oct
(73) |
Nov
(51) |
Dec
(24) |
| 2014 |
Jan
(24) |
Feb
(41) |
Mar
(39) |
Apr
(5) |
May
(6) |
Jun
(2) |
Jul
(5) |
Aug
(15) |
Sep
(7) |
Oct
(6) |
Nov
|
Dec
(7) |
| 2015 |
Jan
(27) |
Feb
(18) |
Mar
(37) |
Apr
(8) |
May
(13) |
Jun
(44) |
Jul
(4) |
Aug
(50) |
Sep
(35) |
Oct
(6) |
Nov
(24) |
Dec
(19) |
| 2016 |
Jan
(30) |
Feb
(30) |
Mar
(23) |
Apr
(4) |
May
(12) |
Jun
(19) |
Jul
(26) |
Aug
(13) |
Sep
|
Oct
(23) |
Nov
(37) |
Dec
(15) |
| 2017 |
Jan
(33) |
Feb
(19) |
Mar
(20) |
Apr
(43) |
May
(39) |
Jun
(23) |
Jul
(20) |
Aug
(27) |
Sep
(10) |
Oct
(15) |
Nov
|
Dec
(24) |
| 2018 |
Jan
(3) |
Feb
(10) |
Mar
(34) |
Apr
(34) |
May
(28) |
Jun
(50) |
Jul
(27) |
Aug
(75) |
Sep
(21) |
Oct
(42) |
Nov
(25) |
Dec
(31) |
| 2019 |
Jan
(39) |
Feb
(28) |
Mar
(19) |
Apr
(7) |
May
(30) |
Jun
(22) |
Jul
(54) |
Aug
(36) |
Sep
(19) |
Oct
(33) |
Nov
(36) |
Dec
(32) |
| 2020 |
Jan
(29) |
Feb
(38) |
Mar
(29) |
Apr
(30) |
May
(39) |
Jun
(45) |
Jul
(31) |
Aug
(52) |
Sep
(40) |
Oct
(8) |
Nov
(48) |
Dec
(30) |
| 2021 |
Jan
(35) |
Feb
(32) |
Mar
(23) |
Apr
(55) |
May
(43) |
Jun
(63) |
Jul
(17) |
Aug
(24) |
Sep
(9) |
Oct
(31) |
Nov
(67) |
Dec
(55) |
| 2022 |
Jan
(31) |
Feb
(48) |
Mar
(76) |
Apr
(18) |
May
(13) |
Jun
(46) |
Jul
(75) |
Aug
(54) |
Sep
(59) |
Oct
(65) |
Nov
(44) |
Dec
(7) |
| 2023 |
Jan
(38) |
Feb
(32) |
Mar
(35) |
Apr
(23) |
May
(46) |
Jun
(53) |
Jul
(18) |
Aug
(10) |
Sep
(24) |
Oct
(15) |
Nov
(40) |
Dec
(6) |
|
From: Richard C. <ric...@gm...> - 2014-03-04 16:17:42
|
On Tue, Mar 04, 2014 at 03:48:57PM +0000, Pham, Calvin wrote:
> Calvin> output of strace
> strace ./testptp -d /dev/ptp0 -g
...
> clock_gettime(0xffffffe3 /* CLOCK_??? */, {1393947888, 731912808}) = 0
The kernel returns zero.
> Calvin> Here is output of ltrace
>
> [root@V4-CALVIN ptptest]# ltrace ./testptp -d /dev/ptp0 -g
...
> clock_gettime(0xffffffdb, 0x7fff7d779690, 0x7fff7d779690, -1, 0) = 0xffffffff
But your C library returns -1.
This is a bug in your C library.
What distro and C library are you using?
Thanks,
Richard
|
|
From: Pham, C. <Cal...@ne...> - 2014-03-04 15:49:11
|
Richard,
Calvin> output of strace
strace ./testptp -d /dev/ptp0 -g
execve("./testptp", ["./testptp", "-d", "/dev/ptp0", "-g"], [/* 20 vars */]) = 0
brk(0) = 0x1aa3000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0f8e45d000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=41323, ...}) = 0
mmap(NULL, 41323, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f0f8e452000
close(3) = 0
open("/lib64/librt.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\"@\2265\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=48128, ...}) = 0
mmap(0x3596400000, 2128984, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3596400000
mprotect(0x3596407000, 2093056, PROT_NONE) = 0
mmap(0x3596606000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x3596606000
close(3) = 0
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\27\202\2255\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=2076800, ...}) = 0
mmap(0x3595800000, 3896632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3595800000
mprotect(0x35959ad000, 2097152, PROT_NONE) = 0
mmap(0x3595bad000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ad000) = 0x3595bad000
mmap(0x3595bb3000, 17720, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3595bb3000
close(3) = 0
open("/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320k\0\2265\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=145176, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0f8e451000
mmap(0x3596000000, 2208760, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3596000000
mprotect(0x3596017000, 2093056, PROT_NONE) = 0
mmap(0x3596216000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16000) = 0x3596216000
mmap(0x3596218000, 13304, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3596218000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0f8e450000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0f8e44f000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0f8e44e000
arch_prctl(ARCH_SET_FS, 0x7f0f8e44f700) = 0
mprotect(0x3595bad000, 16384, PROT_READ) = 0
mprotect(0x3596216000, 4096, PROT_READ) = 0
mprotect(0x3596606000, 4096, PROT_READ) = 0
mprotect(0x3595621000, 4096, PROT_READ) = 0
munmap(0x7f0f8e452000, 41323) = 0
set_tid_address(0x7f0f8e44f9d0) = 2589
set_robust_list(0x7f0f8e44f9e0, 24) = 0
rt_sigaction(SIGRTMIN, {0x3596006720, [], SA_RESTORER|SA_SIGINFO, 0x359600f500}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x35960067b0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x359600f500}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
open("/dev/ptp0", O_RDWR) = 3
clock_gettime(0xffffffe3 /* CLOCK_??? */, {1393947888, 731912808}) = 0
open("/proc/cpuinfo", O_RDONLY) = 4
read(4, "processor\t: 0\nvendor_id\t: Genuin"..., 4096) = 3764
close(4) = 0
dup(2) = 4
fcntl(4, F_GETFL) = 0x8402 (flags O_RDWR|O_APPEND|O_LARGEFILE)
brk(0) = 0x1aa3000
brk(0x1ac4000) = 0x1ac4000
brk(0) = 0x1ac4000
fstat(4, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0f8e45c000
lseek(4, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(4, "clock_gettime %m: Invalid argume"..., 35clock_gettime %m: Invalid argument
) = 35
close(4) = 0
munmap(0x7f0f8e45c000, 4096) = 0
close(3) = 0
exit_group(0) = ?
+++ exited with 0 +++
Calvin> Here is output of ltrace
[root@V4-CALVIN ptptest]# ltrace ./testptp -d /dev/ptp0 -g
unexpected breakpoint at 0x35954016df
(0, 0, 0, -1, 0x1f25bc2) = 0x3595623260
__libc_start_main(0x400ed4, 4, 0x7fff7d779898, 0x401790, 0x401820 <unfinished ...>
strrchr("./testptp", '/') = "/testptp"
getopt(4, 0x7fff7d779898, "a:A:cd:e:f:ghp:P:sSt:v") = 100
getopt(4, 0x7fff7d779898, "a:A:cd:e:f:ghp:P:sSt:v") = 103
getopt(4, 0x7fff7d779898, "a:A:cd:e:f:ghp:P:sSt:v") = -1
open("/dev/ptp0", 2, 022556611134) = 4
clock_gettime(0xffffffdb, 0x7fff7d779690, 0x7fff7d779690, -1, 0) = 0xffffffff
perror("clock_gettime %m"clock_gettime %m: Invalid argument
) = <void>
close(4) = 0
+++ exited (status 0) +++
Thanks!
Calvin
-----Original Message-----
From: Richard Cochran [mailto:ric...@gm...]
Sent: Tuesday, March 04, 2014 10:18 AM
To: Pham, Calvin
Cc: lin...@li...
Subject: Re: [Linuxptp-users] phc2sys[273995.639]: failed to read clock: Invalid argument
On Tue, Mar 04, 2014 at 01:55:56PM +0000, Pham, Calvin wrote:
>
> > testptp -g
> [root@V4-CALVIN ptp]# ./testptp -g
> gettime: CLK_ID 0xffffffe3
> clock time: 1393941119.523279956 or Tue Mar 4 08:51:59 2014
> clock_gettime %m: Invalid argument
[ It looks like you changed testptp to always print the time. ]
I looked at the igb driver, and it always returns 0 for its gettime method. So now this looks more like a glibc bug.
Can you run 'testptp -g' under strace and ltrace and post the results?
Thanks,
Richard
|
|
From: Richard C. <ric...@gm...> - 2014-03-04 15:18:18
|
On Tue, Mar 04, 2014 at 01:55:56PM +0000, Pham, Calvin wrote: > > > testptp -g > [root@V4-CALVIN ptp]# ./testptp -g > gettime: CLK_ID 0xffffffe3 > clock time: 1393941119.523279956 or Tue Mar 4 08:51:59 2014 > clock_gettime %m: Invalid argument [ It looks like you changed testptp to always print the time. ] I looked at the igb driver, and it always returns 0 for its gettime method. So now this looks more like a glibc bug. Can you run 'testptp -g' under strace and ltrace and post the results? Thanks, Richard |
|
From: Pham, C. <Cal...@ne...> - 2014-03-04 13:56:05
|
Hi Richard,
Below is the outputs of the commands. The current ethtool version doesn't support -T option so I have to compile version 3.7 and run for the source directory. Thanks for your help!
> the output of uname -a
[root@V4-CALVIN ~]# uname -a
Linux V4-CALVIN 3.7.5 #1 SMP Tue Feb 26 16:40:13 MST 2013 x86_64 x86_64 x86_64 GNU/Linux
> ethtool -T eth0
[root@V4-CALVIN ethtool-3.7]# ./ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)
software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
all (HWTSTAMP_FILTER_ALL)
> testptp -g
[root@V4-CALVIN ptp]# ./testptp -g
gettime: CLK_ID 0xffffffe3
clock time: 1393941119.523279956 or Tue Mar 4 08:51:59 2014
clock_gettime %m: Invalid argument
> ethtool -i eth0
[root@V4-CALVIN ptp]# ethtool -i eth0
driver: igb
version: 5.0.6
firmware-version: 1.61, 0x8000090e
bus-info: 0000:08:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
-----Original Message-----
From: Richard Cochran [mailto:ric...@gm...]
Sent: Tuesday, March 04, 2014 4:27 AM
To: Pham, Calvin
Cc: lin...@li...
Subject: Re: [Linuxptp-users] phc2sys[273995.639]: failed to read clock: Invalid argument
On Mon, Mar 03, 2014 at 09:06:37PM +0000, Pham, Calvin wrote:
> I forced the code to ignore the error by commenting out "return 0", phc2sys seemed to work fine; I mean the system clock was able to sync to /dev/ptp0 fine. Does anyone know why?
This sounds like a driver bug. Can you give the output of the following commands?
uname -a
ethtool -T eth0
testptp -g
Thanks,
Richard
|
|
From: Richard C. <ric...@gm...> - 2014-03-04 09:26:48
|
On Mon, Mar 03, 2014 at 09:06:37PM +0000, Pham, Calvin wrote:
> I forced the code to ignore the error by commenting out "return 0", phc2sys seemed to work fine; I mean the system clock was able to sync to /dev/ptp0 fine. Does anyone know why?
This sounds like a driver bug. Can you give the output of the
following commands?
uname -a
ethtool -T eth0
testptp -g
Thanks,
Richard
|
|
From: Pham, C. <Cal...@ne...> - 2014-03-03 21:19:35
|
Hi all,
I've been trying to run phc2sys but it kept print this message on the screen and the system clock was found not able to sync to /dev/ptp0. My command was: ./phc2sys -w -s /dev/ptp0 -m
phc2sys[273995.639]: failed to read clock: Invalid argument
phc2sys[273996.639]: failed to read clock: Invalid argument
phc2sys[273997.639]: failed to read clock: Invalid argument
phc2sys[273998.639]: failed to read clock: Invalid argument
phc2sys[273999.639]: failed to read clock: Invalid argument
I am running kernel 3.7.5., intel I350 and linuxptp-1.4. I've found that the print messages came from the function call: clock_gettime(clkid, &tsrc) at line 106 in phc2sys.c:
if (clock_gettime(sysclk, &tdst1) ||
clock_gettime(clkid, &tsrc) ||
clock_gettime(sysclk, &tdst2)) {
pr_err("failed to read clock: %m");
return 0;
}
I forced the code to ignore the error by commenting out "return 0", phc2sys seemed to work fine; I mean the system clock was able to sync to /dev/ptp0 fine. Does anyone know why?
Thanks!
Calvin Pham
|
|
From: Vick, M. <mat...@in...> - 2014-03-03 16:38:05
|
On 3/3/14, 12:25 AM, "Thomas Mayer" <tm....@gm...> wrote: >On 27.02.2014 16:37, Vick, Matthew wrote: >> On 2/27/14, 6:03 AM, "Thomas Mayer" <tm....@gm...> wrote: >> >>> On 26.02.2014 17:53, Vick, Matthew wrote: >>>> On 2/26/14, 8:51 AM, "Vick, Matthew" <mat...@in...> wrote: >>>> >>>>> On 2/26/14, 5:04 AM, "Thomas Mayer" <tm....@gm...> wrote: >>>>> >>>>>> Thanks for your very fast help! >>>>>> Good to know it's not my fault :D >>>>>> According to this mail >>>>>> >>>>>>"http://article.gmane.org/gmane.comp.linux.ptp.user/676/match=82574l" >>>>>> I >>>>>> can hope for a fix :) >>>>>> >>>>>> Regards, >>>>>> Thomas >>>>> >>>>> Thomas, >>>>> >>>>> We have posted a new version of e1000e to our SourceForge website >>>>> (http://sourceforge.net/projects/e1000/) for our out-of-tree driver >>>>>for >>>>> 82574L that contains our proposed fix for this issue. Please give >>>>>this >>>>> a >>>>> try and let us know if it resolves the weirdness you're seeing. We're >>>>> still working on the upstream equivalent for this patch. >>>>> >>>>> Cheers, >>>>> Matthew >>>>> >>>>> Matthew Vick >>>>> Linux Development >>>>> Networking Division >>>>> Intel Corporation >>>> >>>> Sorry for the double response, but I just realized I left out the >>>> version >>>> number you'll need (just in case): 3.0.4, which is the most recent >>>> version >>>> at the time of this e-mail. >>>> >>>> Cheers, >>>> Matthew >>>> >>>> >>> >>> Hi Matthew, >>> >>> first short test looks good :) >>> I will start a long test over the weekend and let you know if something >>> goes wrong. >>> >>> Regards, >>> Thomas >> >> Happy to hear it! :) >> >> I look forward to the results of your weekend test. >> >> Cheers, >> Matthew >> >> >Hi Matthew, > >tested with 2 devices and ptp4l + phc2sys for about 89 hours without >problems :) ...I would say this bug is fixed ;) > >Regards, >Thomas Thomas, Excellent! I'll feed information back into the team internally and we'll continue to work on the upstream patch. Thank you for testing out this fix! Cheers, Matthew |
|
From: Thomas M. <tm....@gm...> - 2014-03-03 08:25:28
|
On 27.02.2014 16:37, Vick, Matthew wrote: > On 2/27/14, 6:03 AM, "Thomas Mayer" <tm....@gm...> wrote: > >> On 26.02.2014 17:53, Vick, Matthew wrote: >>> On 2/26/14, 8:51 AM, "Vick, Matthew" <mat...@in...> wrote: >>> >>>> On 2/26/14, 5:04 AM, "Thomas Mayer" <tm....@gm...> wrote: >>>> >>>>> Thanks for your very fast help! >>>>> Good to know it's not my fault :D >>>>> According to this mail >>>>> "http://article.gmane.org/gmane.comp.linux.ptp.user/676/match=82574l" >>>>> I >>>>> can hope for a fix :) >>>>> >>>>> Regards, >>>>> Thomas >>>> >>>> Thomas, >>>> >>>> We have posted a new version of e1000e to our SourceForge website >>>> (http://sourceforge.net/projects/e1000/) for our out-of-tree driver for >>>> 82574L that contains our proposed fix for this issue. Please give this >>>> a >>>> try and let us know if it resolves the weirdness you're seeing. We're >>>> still working on the upstream equivalent for this patch. >>>> >>>> Cheers, >>>> Matthew >>>> >>>> Matthew Vick >>>> Linux Development >>>> Networking Division >>>> Intel Corporation >>> >>> Sorry for the double response, but I just realized I left out the >>> version >>> number you'll need (just in case): 3.0.4, which is the most recent >>> version >>> at the time of this e-mail. >>> >>> Cheers, >>> Matthew >>> >>> >> >> Hi Matthew, >> >> first short test looks good :) >> I will start a long test over the weekend and let you know if something >> goes wrong. >> >> Regards, >> Thomas > > Happy to hear it! :) > > I look forward to the results of your weekend test. > > Cheers, > Matthew > > Hi Matthew, tested with 2 devices and ptp4l + phc2sys for about 89 hours without problems :) ...I would say this bug is fixed ;) Regards, Thomas |
|
From: Vick, M. <mat...@in...> - 2014-02-27 15:37:45
|
On 2/27/14, 6:03 AM, "Thomas Mayer" <tm....@gm...> wrote: >On 26.02.2014 17:53, Vick, Matthew wrote: >> On 2/26/14, 8:51 AM, "Vick, Matthew" <mat...@in...> wrote: >> >>> On 2/26/14, 5:04 AM, "Thomas Mayer" <tm....@gm...> wrote: >>> >>>> Thanks for your very fast help! >>>> Good to know it's not my fault :D >>>> According to this mail >>>> "http://article.gmane.org/gmane.comp.linux.ptp.user/676/match=82574l" >>>>I >>>> can hope for a fix :) >>>> >>>> Regards, >>>> Thomas >>> >>> Thomas, >>> >>> We have posted a new version of e1000e to our SourceForge website >>> (http://sourceforge.net/projects/e1000/) for our out-of-tree driver for >>> 82574L that contains our proposed fix for this issue. Please give this >>>a >>> try and let us know if it resolves the weirdness you're seeing. We're >>> still working on the upstream equivalent for this patch. >>> >>> Cheers, >>> Matthew >>> >>> Matthew Vick >>> Linux Development >>> Networking Division >>> Intel Corporation >> >> Sorry for the double response, but I just realized I left out the >>version >> number you'll need (just in case): 3.0.4, which is the most recent >>version >> at the time of this e-mail. >> >> Cheers, >> Matthew >> >> > >Hi Matthew, > >first short test looks good :) >I will start a long test over the weekend and let you know if something >goes wrong. > >Regards, >Thomas Happy to hear it! :) I look forward to the results of your weekend test. Cheers, Matthew |
|
From: Thomas M. <tm....@gm...> - 2014-02-27 14:03:57
|
On 26.02.2014 17:53, Vick, Matthew wrote: > On 2/26/14, 8:51 AM, "Vick, Matthew" <mat...@in...> wrote: > >> On 2/26/14, 5:04 AM, "Thomas Mayer" <tm....@gm...> wrote: >> >>> Thanks for your very fast help! >>> Good to know it's not my fault :D >>> According to this mail >>> "http://article.gmane.org/gmane.comp.linux.ptp.user/676/match=82574l" I >>> can hope for a fix :) >>> >>> Regards, >>> Thomas >> >> Thomas, >> >> We have posted a new version of e1000e to our SourceForge website >> (http://sourceforge.net/projects/e1000/) for our out-of-tree driver for >> 82574L that contains our proposed fix for this issue. Please give this a >> try and let us know if it resolves the weirdness you're seeing. We're >> still working on the upstream equivalent for this patch. >> >> Cheers, >> Matthew >> >> Matthew Vick >> Linux Development >> Networking Division >> Intel Corporation > > Sorry for the double response, but I just realized I left out the version > number you'll need (just in case): 3.0.4, which is the most recent version > at the time of this e-mail. > > Cheers, > Matthew > > Hi Matthew, first short test looks good :) I will start a long test over the weekend and let you know if something goes wrong. Regards, Thomas |
|
From: Vick, M. <mat...@in...> - 2014-02-26 16:54:08
|
On 2/26/14, 8:51 AM, "Vick, Matthew" <mat...@in...> wrote: >On 2/26/14, 5:04 AM, "Thomas Mayer" <tm....@gm...> wrote: > >>Thanks for your very fast help! >>Good to know it's not my fault :D >>According to this mail >>"http://article.gmane.org/gmane.comp.linux.ptp.user/676/match=82574l" I >>can hope for a fix :) >> >>Regards, >>Thomas > >Thomas, > >We have posted a new version of e1000e to our SourceForge website >(http://sourceforge.net/projects/e1000/) for our out-of-tree driver for >82574L that contains our proposed fix for this issue. Please give this a >try and let us know if it resolves the weirdness you're seeing. We're >still working on the upstream equivalent for this patch. > >Cheers, >Matthew > >Matthew Vick >Linux Development >Networking Division >Intel Corporation Sorry for the double response, but I just realized I left out the version number you'll need (just in case): 3.0.4, which is the most recent version at the time of this e-mail. Cheers, Matthew |
|
From: Vick, M. <mat...@in...> - 2014-02-26 16:51:58
|
On 2/26/14, 5:04 AM, "Thomas Mayer" <tm....@gm...> wrote: >Thanks for your very fast help! >Good to know it's not my fault :D >According to this mail >"http://article.gmane.org/gmane.comp.linux.ptp.user/676/match=82574l" I >can hope for a fix :) > >Regards, >Thomas Thomas, We have posted a new version of e1000e to our SourceForge website (http://sourceforge.net/projects/e1000/) for our out-of-tree driver for 82574L that contains our proposed fix for this issue. Please give this a try and let us know if it resolves the weirdness you're seeing. We're still working on the upstream equivalent for this patch. Cheers, Matthew Matthew Vick Linux Development Networking Division Intel Corporation |
|
From: Thomas M. <tm....@gm...> - 2014-02-26 13:04:35
|
Thanks for your very fast help! Good to know it's not my fault :D According to this mail "http://article.gmane.org/gmane.comp.linux.ptp.user/676/match=82574l" I can hope for a fix :) Regards, Thomas On 26.02.2014 13:25, Richard Cochran wrote: > On Wed, Feb 26, 2014 at 01:07:25PM +0100, Thomas Mayer wrote: >> Hi everybody, >> for a little project at our company I try to sync the system clocks of >> two devices. Both devices use a Intel 82574L network interface. On the > > ... > >> I guess this big time jumps are not normal, so do anybody know how I can >> fix this problem? > > There appears to be hardware bug with the 82574L. See the thread starting with: > > http://article.gmane.org/gmane.comp.linux.ptp.user/665 > > Sorry, > Richard > |
|
From: Richard C. <ric...@gm...> - 2014-02-26 12:26:24
|
On Wed, Feb 26, 2014 at 01:07:25PM +0100, Thomas Mayer wrote:
> Hi everybody,
> for a little project at our company I try to sync the system clocks of
> two devices. Both devices use a Intel 82574L network interface. On the
...
> I guess this big time jumps are not normal, so do anybody know how I can
> fix this problem?
There appears to be hardware bug with the 82574L. See the thread starting with:
http://article.gmane.org/gmane.comp.linux.ptp.user/665
Sorry,
Richard
|
|
From: Thomas M. <tm....@gm...> - 2014-02-26 12:07:34
|
Hi everybody, for a little project at our company I try to sync the system clocks of two devices. Both devices use a Intel 82574L network interface. On the PTP-master phc2sys is used to sync CLOCK_REALTIME to /dev/ptp0. On the PTP-slave phy2sys is used to sync /dev/ptp0 to CLOCK_REALTIME. Linux Kernel v3.12.2 is used. Basically the whole sync process seems to work, but from time to time the /dev/ptp0 device do a big time jump (sometimes on master, sometimes on slave). Log output of the PTP slave: /var/src/linuxptp # ./ptp4l -i eth0 -m -l6 -s ptp4l[67389.205]: selected /dev/ptp0 as PTP clock ptp4l[67389.208]: port 1: INITIALIZING to LISTENING on INITIALIZE ptp4l[67389.209]: port 0: INITIALIZING to LISTENING on INITIALIZE ptp4l[67394.495]: port 1: new foreign master 0013ab.fffe.004874-1 ptp4l[67396.079]: selected best master clock 0013ab.fffe.003ea2 ptp4l[67398.596]: selected best master clock 0013ab.fffe.004874 ptp4l[67398.596]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[67400.596]: master offset 692552075142917737 s0 freq +44869 path delay -3816 ptp4l[67401.596]: master offset 692552075142969782 s1 freq +96896 path delay -10659 ptp4l[67402.596]: master offset -47285 s2 freq +49611 path delay -10659 ptp4l[67402.596]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[67403.597]: master offset -56417 s2 freq +26293 path delay -10659 ptp4l[67404.597]: master offset -45713 s2 freq +20072 path delay -4808 ptp4l[67405.599]: master offset -21317 s2 freq +30754 path delay -4808 ptp4l[67406.597]: master offset -6970 s2 freq +38706 path delay -3816 ptp4l[67407.597]: master offset -961 s2 freq +42624 path delay -2878 ptp4l[67408.686]: master offset 245 s2 freq +43542 path delay -1401 ... ptp4l[67877.698]: master offset -109 s2 freq +44802 path delay 728 ptp4l[67878.698]: master offset -29 s2 freq +44850 path delay 728 ptp4l[67879.611]: clockcheck: clock jumped forward or running faster than expected! ptp4l[67879.721]: master offset 70368744177690 s0 freq +44850 path delay 725 ptp4l[67879.722]: port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT ptp4l[67880.822]: master offset 70368744177750 s1 freq +44930 path delay 720 ptp4l[67881.840]: master offset -5688 s2 freq +39242 path delay 720 ptp4l[67881.840]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[67882.748]: master offset -584 s2 freq +42640 path delay 712 ptp4l[67883.690]: master offset 2016 s2 freq +45064 path delay 702 ptp4l[67884.679]: master offset 2126 s2 freq +45779 path delay 695 ... I tried a few things to locate the reason for this behavior, and find out it's possible to decrease the time between this time jumps dramatically by do a lot of clk_getime() calls on the ptp device. For this test a modified the kernel testptp tool to read the time in a loop. Log output: /var/src # ./testptp -d /dev/ptp0 -g readCount=1; clock time: 1394816657.943618751 or Fri Mar 14 17:04:17 2014 readCount=2; clock time: 1394816657.944179005 or Fri Mar 14 17:04:17 2014 ... readCount=41985; clock time: 1394816661.206155491 or Fri Mar 14 17:04:21 2014 readCount=41986; clock time: 1394816661.206209448 or Fri Mar 14 17:04:21 2014 readCount=41987; clock time: 1394887029.949932637 or Sat Mar 15 12:37:09 2014 readCount=41988; clock time: 1394887029.950497306 or Sat Mar 15 12:37:09 2014 ... readCount=73430; clock time: 1394887032.177426719 or Sat Mar 15 12:37:12 2014 readCount=73431; clock time: 1394887032.177519354 or Sat Mar 15 12:37:12 2014 readCount=73432; clock time: 1394957400.921267022 or Sun Mar 16 08:10:00 2014 readCount=73433; clock time: 1394957400.921897480 or Sun Mar 16 08:10:00 2014 ... I guess this big time jumps are not normal, so do anybody know how I can fix this problem? Regards, Thomas |
|
From: Julien H. <ju...@ya...> - 2014-02-21 13:53:14
|
You can try to synchronize several PCs with a standard switch. I measured the delay with one master and one slave and then slightly modified ptp4l with the value obtained (hardcoded). I disabled the delay req messages on the slaves (to avoid messages accumulation on the master side). There is no other traffic on the links. I could measure a delta of a few hundred ns between master and slaves with the oscilloscope and i210 with PPS generation enabled. I use the following schema : |------ netgear GS724T ------ slaves master ---- netgear GS108E |------ netgear GS724T ------ slaves |------ netgear GS724T ------ slaves The result is even better when I use less slaves and a single GS108E (a few tens of ns). But on three GS108E, two give very good results and one is very bad... The best is to test. Julien. ________________________________ De : Richard Cochran <ric...@gm...> À : Koehrer Mathias (ETAS/ESW5) <mat...@et...> Cc : "lin...@li..." <lin...@li...> Envoyé le : Vendredi 21 février 2014 14h33 Objet : Re: [Linuxptp-users] One PCs with multiple NICs acting as multiple PTP master / PTP chains On Fri, Feb 21, 2014 at 01:16:09PM +0000, Koehrer Mathias (ETAS/ESW5) wrote: > Hi all, > > to synchronize a couple (6-8) PCs I want to use one PCs PTP master and the others as PTP slaves. > To interconnect the PCs I can use a PTP capable switch. However these switches are fairly expensive. > The first question I have: How does a "standard" Ethernet switch perform? Which accuracy will be possible if no other traffic is running over the switch but PTP packets? The answer is, it depends. It depends on the switch itself and the amount of traffic through the switch. Usually switches add something like 10 microseconds delay and a few microseconds jitter. I would definitely try this first and just see what kind of RMS numbers come out. > As PC 1 ... PC 7 have two PTP clocks running, these clocks have to be synchronized. > Is this done via phc2sys? If yes, do I have to synchronize directly from PTPx to PTPy or does it work via the PCs System clock? You can use phc2sys to synchronize the PHC clock pairs. However, this will be a PITA to set up, and remember, unless you feed signals from one card to the next, you will be using a kind of software time stamping. Chaining those servos together accumulates the errors. I would guess that the normal switch would perform much better. Try the switch idea first. HTH, Richard ------------------------------------------------------------------------------ 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 _______________________________________________ Linuxptp-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Richard C. <ric...@gm...> - 2014-02-21 13:34:06
|
On Fri, Feb 21, 2014 at 01:16:09PM +0000, Koehrer Mathias (ETAS/ESW5) wrote: > Hi all, > > to synchronize a couple (6-8) PCs I want to use one PCs PTP master and the others as PTP slaves. > To interconnect the PCs I can use a PTP capable switch. However these switches are fairly expensive. > The first question I have: How does a "standard" Ethernet switch perform? Which accuracy will be possible if no other traffic is running over the switch but PTP packets? The answer is, it depends. It depends on the switch itself and the amount of traffic through the switch. Usually switches add something like 10 microseconds delay and a few microseconds jitter. I would definitely try this first and just see what kind of RMS numbers come out. > As PC 1 ... PC 7 have two PTP clocks running, these clocks have to be synchronized. > Is this done via phc2sys? If yes, do I have to synchronize directly from PTPx to PTPy or does it work via the PCs System clock? You can use phc2sys to synchronize the PHC clock pairs. However, this will be a PITA to set up, and remember, unless you feed signals from one card to the next, you will be using a kind of software time stamping. Chaining those servos together accumulates the errors. I would guess that the normal switch would perform much better. Try the switch idea first. HTH, Richard |
|
From: Koehrer M. (ETAS/ESW5) <mat...@et...> - 2014-02-21 13:16:23
|
Hi all, to synchronize a couple (6-8) PCs I want to use one PCs PTP master and the others as PTP slaves. To interconnect the PCs I can use a PTP capable switch. However these switches are fairly expensive. The first question I have: How does a "standard" Ethernet switch perform? Which accuracy will be possible if no other traffic is running over the switch but PTP packets? To avoid a PTP capable switch I can think of a solution to use one PC as PTP master, to plug in two 4-port NICs in this master PC and use point-to-point connections to the other PCs. Assume the Ethernet devices to be used by the PTP master are eth1, eth2, ...eth7 it should be possible to run something like ptp4l -p /dev/ptp1 -i eth1 & ptp4l -p /dev/ptp2 -i eth2 & ... ptp4l -p /dev/ptp7 -i eth7 & Is this assumption correct? Is it possible to set up a system like that. A different approach could be to run something like a "chain" of point-to-point Ethernet connections: [PC MASTER] --- (eth) --- [PC 1] --- (eth) --- [PC 2] --- (eth) --- [PC 3] --- (eth) --- [PC 4] --- ... The first PC (PC MASTER) acts as overall time master. It is the master on the Ethernet connection between PC Master and PC 1. PC 1 is slave on this Ethernet and acts as a master on the Ethernet between PC 1 and PC 2. etc. Doing this, the accuracy decreases with each member of the chain; however the overall accuracy could be good enough. My question is here: How does the configuration of PC 1 ... PC 7 look like? As PC 1 ... PC 7 have two PTP clocks running, these clocks have to be synchronized. Is this done via phc2sys? If yes, do I have to synchronize directly from PTPx to PTPy or does it work via the PCs System clock? Thanks for any hints or recommendations Regards Mathias |
|
From: Richard C. <ric...@gm...> - 2014-02-21 09:29:28
|
On Fri, Feb 21, 2014 at 10:11:33AM +0100, Miroslav Lichvar wrote: > > Hm, should we set the kernel TAI offset (ADJ_TAI) in ptp4l > and phc2sys? I think we should if: 1. the node is slaved to a GM 2. the GM timescale is PTP and is traceable 3. the reported TAI offset differs from the kernel's Thanks, Richard |
|
From: Miroslav L. <mli...@re...> - 2014-02-21 09:11:42
|
On Fri, Feb 21, 2014 at 10:03:12AM +0100, Richard Cochran wrote: > On Fri, Feb 21, 2014 at 09:58:12AM +0100, Richard Cochran wrote: > > On Fri, Feb 21, 2014 at 08:50:43AM +0000, Ledda William EXT wrote: > > > Which is the kernel version that include CLOCK_TAI? > > > > v3.10 > > But there was an early bug. Make sure you use the latest stable > kernel. Hm, should we set the kernel TAI offset (ADJ_TAI) in ptp4l and phc2sys? -- Miroslav Lichvar |
|
From: Richard C. <ric...@gm...> - 2014-02-21 09:03:31
|
On Fri, Feb 21, 2014 at 09:58:12AM +0100, Richard Cochran wrote: > On Fri, Feb 21, 2014 at 08:50:43AM +0000, Ledda William EXT wrote: > > Which is the kernel version that include CLOCK_TAI? > > v3.10 But there was an early bug. Make sure you use the latest stable kernel. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2014-02-21 08:58:31
|
On Fri, Feb 21, 2014 at 08:50:43AM +0000, Ledda William EXT wrote: > Which is the kernel version that include CLOCK_TAI? v3.10 HTH, Richard |
|
From: Ledda W. E. <Wil...@it...> - 2014-02-21 08:50:53
|
Richard, > Well, now that we have CLOCK_TAI in Linux, that takes of the leap second issue. Which is the kernel version that include CLOCK_TAI? Thanks William -----Original Message----- From: Richard Cochran [mailto:ric...@gm...] Sent: 19 February 2014 16:08 To: Ledda William EXT Cc: Koehrer Mathias (ETAS/ESW5); lin...@li... Subject: Re: [Linuxptp-users] clock_nanosleep on /dev/ptpX On Wed, Feb 19, 2014 at 02:58:40PM +0000, Ledda William EXT wrote: > > I might do it one day, but so far I haven't had a really compelling > > reason to do so. Probably using the Linux system clock (and phc2sys) will be good enough most of the time. It would be interesting to find out whether that is true for your own application. > > Richard, > Think about this "simple" but very interesting problem. System time is not monotonic (assuming it is in UTC), PTP time yes (assuming it is TAI). In a real time control system you could have the need to make a "wait_until" or to execute some functions in a very well-defined time in spite of any clock adjustment made to recover some UTC leap second event. This could be a valid reason to implement these features on a PHC? Well, now that we have CLOCK_TAI in Linux, that takes of the leap second issue. I agree that it would be nice to have the PHC timers, but considering the scheduling latency on typical Linux systems (even RT), I do think using the system CLOCK_REALTIME or CLOCK_TAI will be good enough. In fact, timers built off of PHC devices which are PCIe cards will probably have *worse* latency than using system timers. I would expect that only register based SoC devices (like the gianfar) would bring any benefit at all. Thanks, Richard |
|
From: Julien H. <ju...@ya...> - 2014-02-19 16:03:54
|
I wanted to send packets bursts on gigabit ports spread on numerous computers at precise dates specified in a common scenario. I could achieve a ~200ns jitter among packets in a burst by synchronizing the computers (only two at this time...) with a slightly modified ptp4l and phc2sys (dedicated gbe links for synchronization) and a task in a dedicated module which waits on msleep_interruptible, usleep_range, ndelay or a polling with getnstimeofday depending on the interval between the different dates in scenario. This task triggers the packet sending at the date wanted. I rapidly gave up timers for small intervals because of the scheduling latency. Julien. ________________________________ De : Richard Cochran <ric...@gm...> À : Ledda William EXT <Wil...@it...> Cc : "lin...@li..." <lin...@li...> Envoyé le : Mercredi 19 février 2014 16h08 Objet : Re: [Linuxptp-users] clock_nanosleep on /dev/ptpX On Wed, Feb 19, 2014 at 02:58:40PM +0000, Ledda William EXT wrote: > > I might do it one day, but so far I haven't had a really compelling reason to do so. Probably using the Linux system clock (and phc2sys) will be good enough > > most of the time. It would be interesting to find out whether that is true for your own application. > > Richard, > Think about this "simple" but very interesting problem. System time is not monotonic (assuming it is in UTC), PTP time yes (assuming it is TAI). In a real time control system you could have the need to make a "wait_until" or to execute some functions in a very well-defined time in spite of any clock adjustment made to recover some UTC leap second event. This could be a valid reason to implement these features on a PHC? Well, now that we have CLOCK_TAI in Linux, that takes of the leap second issue. I agree that it would be nice to have the PHC timers, but considering the scheduling latency on typical Linux systems (even RT), I do think using the system CLOCK_REALTIME or CLOCK_TAI will be good enough. In fact, timers built off of PHC devices which are PCIe cards will probably have *worse* latency than using system timers. I would expect that only register based SoC devices (like the gianfar) would bring any benefit at all. Thanks, Richard ------------------------------------------------------------------------------ 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 _______________________________________________ Linuxptp-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Richard C. <ric...@gm...> - 2014-02-19 15:12:14
|
On Wed, Feb 19, 2014 at 03:03:41PM +0000, Koehrer Mathias (ETAS/ESW5) wrote: > > I think that phc2sys uses clock_adjtime() to modify the clock. > My thought was that this should effect CLOCK_REALTIME and CLOCK_MONOTONIC... > But likely I am wrong. Both CLOCK_REALTIME and CLOCK_MONOTONIC use the same frequency, but CLOCK_MONOTONIC starts with zero at boot time, and it never jumps. So you cannot use it to start tasks on two different machines at the same moment in time. Thanks, Richard |
27 messages has been excluded from this view by a project administrator.
