Comment on SyncML Client for KDE4 by rune

rune — Wed, 17 Feb 2010 22:47:48 +0000

confusionplusplus, you are an idiot.

Stick to Microsoft and come back and comment when you’ve got a clue.

Comment on SyncEvolution Available for Nokia N810 by Synchronisationsgeschichten (3): Adressbuch synchronisieren | maemonews.de

Synchronisationsgeschichten (3): Adressbuch synchronisieren | maemonews.de — Thu, 04 Feb 2010 06:57:57 +0000

[...] existieren eine Menge Fallstricke, die ich bei meinen ersten Installationsversuchen auch brav alle mitgenommen habe. Dank diverser Hinweise des Programmautors hats dann aber irgendwann doch noch [...]

Comment on Magic Tricks Revealed: How SyncML Works and When It Fails by Peter T

Peter T — Thu, 21 Jan 2010 22:13:45 +0000

Thanks for the interesting item. I’m just coming to SyncML on my N900 and finding out all the wrinkles.

Comment on Linux 2.6.30: Hardware Assisted Time Stamping of Network Packets by Christopher Johnston

Christopher Johnston — Tue, 20 Oct 2009 22:27:32 +0000

Is PTPv2 supported with the client and with Intel 82576 NICs with the Kernel hardware assisted timestamping?

Comment on Linux 2.6.30: Hardware Assisted Time Stamping of Network Packets by Barry

Barry — Sun, 27 Sep 2009 03:33:45 +0000

Patrick Ohly,
Thank you very much for you bring-up hardware timestamp supporting in ptpd. I am using it, but unfortunately it doesn’t work.
Case 1:
master Sep 27 2009, slave Jan 5 1970, running ptpd -z linux_hw -g in slave, the log is:

root:/> ptpd -z linux_hw -g

(ptpd debug) allocated 1264 bytes for protocol engine data
(ptpd debug) allocated 600 bytes for foreign master data
(ptpd debug) event POWERUP
(ptpd debug) state PTP_INITIALIZING
(ptpd debug) manufacturerIdentity: Kendall;1.0.0
(ptpd debug) netInit
(ptpd debug) initData
(ptpd debug) initTimer
(ptpd debug) initClock
(ptpd info) requested adj 0 ppb => adjust system frequency by 0 scaled ppm (0 ppb) + 0 us/tick (0 ppb) = adj 0 ppb (freq limit -504123/504123 ppm, tick limit -1000/1000 us*USER_HZ)
(ptpd error) adjtimex -> time bad
(ptpd debug) sync message interval: 2
(ptpd debug) clock identifier: DFLT
(ptpd debug) 256*log2(clock variance): -4000
(ptpd debug) clock stratum: 4
(ptpd debug) clock preferred?: no
(ptpd debug) bound interface name: eth0
(ptpd debug) communication technology: 1
(ptpd debug) uuid: 00:e0:22:fe:5c:e0
(ptpd debug) PTP subdomain name: _DFLT
(ptpd debug) subdomain address: e0.0.1.81
(ptpd debug) event port address: 3f 1
(ptpd debug) general port address: 40 1
(ptpd debug) state PTP_LISTENING
(ptpd debug) updateForeign: new record (0,1) 1 1 00:22:19:0a:46:7d
(ptpd debug) state PTP_PTP_SLAVE
(ptpd debug) initClock
(ptpd info) requested adj 0 ppb => adjust system frequency by 0 scaled ppm (0 ppb) + 0 us/tick (0 ppb) = adj 0 ppb (freq limit -504123/504123 ppm, tick limit -1000/1000 us*USER_HZ)
(ptpd error) adjtimex -> time bad
(ptpd debug) Q = 0, R = 6
(ptpd notice) resetting system clock to 1254021169s 935610415ns
(ptpd debug) initClock
(ptpd info) requested adj 0 ppb => adjust system frequency by 0 scaled ppm (0 ppb) + 0 us/tick (0 ppb) = adj 0 ppb (freq limit -504123/504123 ppm, tick limit -1000/1000 us*USER_HZ)
(ptpd error) adjtimex -> time bad
(ptpd debug) offset from master: -1253605562s -863610415ns
(ptpd debug) observed drift: 0
(ptpd notice) resetting system clock to 2134629930s 225735894ns
(ptpd debug) initClock
(ptpd info) requested adj 0 ppb => adjust system frequency by 0 scaled ppm (0 ppb) + 0 us/tick (0 ppb) = adj 0 ppb (freq limit -504123/504123 ppm, tick limit -1000/1000 us*USER_HZ)
(ptpd error) adjtimex -> time bad
(ptpd debug) offset from master: -880608758s -290125894ns
(ptpd debug) observed drift: 0
(ptpd info) requested adj 11420 ppb => adjust system frequency by 742300 scaled ppm (11420 ppb) + 0 us/tick (0 ppb) = adj 11420 ppb (freq limit -504123/504123 ppm, tick limit -1000/1000 us*USER_HZ)
(ptpd error) adjtimex -> time bad
(ptpd debug) offset from master: 0s -113078ns
(ptpd debug) observed drift: -113
(ptpd info) requested adj 25746 ppb => adjust system frequency by 1673490 scaled ppm (25746 ppb) + 0 us/tick (0 ppb) = adj 25746 ppb (freq limit -504123/504123 ppm, tick limit -1000/1000 us*USER_HZ)
(ptpd error) adjtimex -> time bad
(ptpd debug) offset from master: 0s -253807ns
(ptpd debug) observed drift: -366
(ptpd info) requested adj 24677 ppb => adjust system frequency by 1604005 scaled ppm (24677 ppb) + 0 us/tick (0 ppb) = adj 24677 ppb (freq limit -504123/504123 ppm, tick limit -1000/1000 us*USER_HZ)
(ptpd error) adjtimex -> time bad
(ptpd debug) offset from master: 0s -240717ns
(ptpd debug) observed drift: -606
(ptpd debug) Q = 0, R = 20
(ptpd debug) handleDelayReq: self
(ptpd info) requested adj 18520 ppb => adjust system frequency by 1203800 scaled ppm (18520 ppb) + 0 us/tick (0 ppb) = adj 18520 ppb (freq limit -504123/504123 ppm, tick limit -1000/1000 us*USER_HZ)
(ptpd error) adjtimex -> time bad
(ptpd debug) offset from master: 0s -177371ns
(ptpd debug) observed drift: -783
(ptpd info) requested adj 15849 ppb => adjust system frequency by 1030185 scaled ppm (15849 ppb) + 0 us/tick (0 ppb) = adj 15849 ppb (freq limit -504123/504123 ppm, tick limit -1000/1000 us*USER_HZ)
(ptpd error) adjtimex -> time bad
(ptpd debug) offset from master: 0s -149179ns
(ptpd debug) observed drift: -932
(ptpd info) requested adj 14357 ppb => adjust system frequency by 933205 scaled ppm (14357 ppb) + 0 us/tick (0 ppb) = adj 14357 ppb (freq limit -504123/504123 ppm, tick limit -1000/1000 us*USER_HZ)
(ptpd error) adjtimex -> time bad
(ptpd debug) offset from master: 0s -132939ns
(ptpd debug) observed drift: -1064
(ptpd info) requested adj 11621 ppb => adjust system frequency by 755365 scaled ppm (11621 ppb) + 0 us/tick (0 ppb) = adj 11621 ppb (freq limit -504123/504123 ppm, tick limit -1000/1000 us*USER_HZ)
(ptpd error) adjtimex -> time bad
(ptpd debug) offset from master: 0s -104531ns
(ptpd debug) observed drift: -1168
(ptpd info) requested adj 7668 ppb => adjust system frequency by 498420 scaled ppm (7668 ppb) + 0 us/tick (0 ppb) = adj 7668 ppb (freq limit -504123/504123 ppm, tick limit -1000/1000 us*USER_HZ)
(ptpd error) adjtimex -> time bad
(ptpd debug) offset from master: 0s -64364ns
(ptpd debug) observed drift: -1232
^C(ptpd notice) shutdown on interrupt signal

Then I check the time:
root:/> date
Sun Aug 23 08:45:48 UTC 2037
root:/>
The time is so much different with master’s Sep 27 2009.

Case 2:
After that, I start-up slave ptpd again, then the log is:
root:/> ptpd -z linux_hw -g
(ptpd debug) allocated 1264 bytes for protocol engine data
(ptpd debug) allocated 600 bytes for foreign master data
(ptpd debug) event POWERUP
(ptpd debug) state PTP_INITIALIZING
(ptpd debug) manufacturerIdentity: Kendall;1.0.0
(ptpd debug) netInit
(ptpd debug) initData
(ptpd debug) initTimer
(ptpd debug) initClock
(ptpd info) requested adj 0 ppb => adjust system frequency by 0 scaled ppm (0 ppb) + 0 us/tick (0 ppb) = adj 0 ppb (freq limit -504123/504123 ppm, tick limit -1000/1000 us*USER_HZ)
(ptpd error) adjtimex -> time bad
(ptpd debug) sync message interval: 2
(ptpd debug) clock identifier: DFLT
(ptpd debug) 256*log2(clock variance): -4000
(ptpd debug) clock stratum: 4
(ptpd debug) clock preferred?: no
(ptpd debug) bound interface name: eth0
(ptpd debug) communication technology: 1
(ptpd debug) uuid: 00:e0:22:fe:5c:e0
(ptpd debug) PTP subdomain name: _DFLT
(ptpd debug) subdomain address: e0.0.1.81
(ptpd debug) event port address: 3f 1
(ptpd debug) general port address: 40 1
(ptpd debug) state PTP_LISTENING
(ptpd debug) updateForeign: new record (0,1) 1 1 00:22:19:0a:46:7d
(ptpd debug) state PTP_PTP_SLAVE
(ptpd debug) initClock
(ptpd info) requested adj 0 ppb => adjust system frequency by 0 scaled ppm (0 ppb) + 0 us/tick (0 ppb) = adj 0 ppb (freq limit -504123/504123 ppm, tick limit -1000/1000 us*USER_HZ)
(ptpd error) adjtimex -> time bad
(ptpd debug) Q = 0, R = 6
(ptpd notice) resetting system clock to 766255858s 548470130ns
(ptpd debug) initClock
(ptpd info) requested adj 0 ppb => adjust system frequency by 0 scaled ppm (0 ppb) + 0 us/tick (0 ppb) = adj 0 ppb (freq limit -504123/504123 ppm, tick limit -1000/1000 us*USER_HZ)
(ptpd error) adjtimex -> time bad
(ptpd debug) offset from master: 1368374263s 670814870ns
(ptpd debug) observed drift: 0
(ptpd notice) resetting system clock to -1381227787s -451556678ns
(ptpd debug) initClock
(ptpd info) requested adj 0 ppb => adjust system frequency by 0 scaled ppm (0 ppb) + 0 us/tick (0 ppb) = adj 0 ppb (freq limit -504123/504123 ppm, tick limit -1000/1000 us*USER_HZ)
(ptpd error) adjtimex -> time bad
(ptpd debug) offset from master: -2147483647s -999973322ns
(ptpd debug) observed drift: 0
(ptpd notice) resetting system clock to -1381227785s -451539169ns
(ptpd debug) initClock
(ptpd info) requested adj 0 ppb => adjust system frequency by 0 scaled ppm (0 ppb) + 0 us/tick (0 ppb) = adj 0 ppb (freq limit -504123/504123 ppm, tick limit -1000/1000 us*USER_HZ)
(ptpd error) adjtimex -> time bad
(ptpd debug) offset from master: -2147483647s -999990831ns
(ptpd debug) observed drift: 0
(ptpd notice) resetting system clock to -1381227783s -451487406ns
(ptpd debug) initClock
(ptpd info) requested adj 0 ppb => adjust system frequency by 0 scaled ppm (0 ppb) + 0 us/tick (0 ppb) = adj 0 ppb (freq limit -504123/504123 ppm, tick limit -1000/1000 us*USER_HZ)
(ptpd error) adjtimex -> time bad
(ptpd debug) offset from master: -2147483648s -42594ns
(ptpd debug) observed drift: 0
^C(ptpd notice) shutdown on interrupt signal

Now the time comes to:
root:/> date
Wed Apr 13 16:51:06 UTC 1994
The time is still so much different with master’s Sep 27 2009.

Case 3:
I simple changes the codes in drivers like:
timecompare_update(&adapter->compare, ns);
shhwtstamps.hwtstamp = ns_to_ktime(ns);
shhwtstamps.syststamp =
- timecompare_transform(&adapter->compare, ns);
+ ktime_get_real();
I means replacing transformed hardware time-stamp by system time directly, then then the slave time can sync with master right.

So I want to know whether “ptpd -z linux_hw” can really work.
In ptpd patched by you, there are many ioctl like E1000_TSYNC_SYSTIME_IOCTL,E1000_TSYNC_ADJTIME_IOCTL for “both” and “nic” mode, but the driver codes don’t have them fulfilled. So do hardware timestamp must have them fulfilled to work?

Comment on SyncEvolution 0.9 released by Csaba Kokai

Csaba Kokai — Fri, 25 Sep 2009 11:33:13 +0000

Thanks yout great job

Comment on Running SyncEvolution as cron Job by edin

edin — Wed, 16 Sep 2009 18:00:36 +0000

I need help
I am running a sql file which has to insert around 4033 rows in a specific table. Manually it works fine. But when I use crontab it just insert 71 rows.
The log says after the row 71
2009-09-16 09:57:01 AST LOG: could not send data to client: Broken pipe
2009-09-16 09:57:01 AST LOG: unexpected EOF on client connection

Any suggestion is really appreciated

Comment on Linux 2.6.30: Hardware Assisted Time Stamping of Network Packets by Kate

Kate — Tue, 15 Sep 2009 21:10:30 +0000

Patrick, Thank you for your reply. I was using a wrong driver, just like you said. I found the correct driver and ptpd -z linux_hw works for me now.

Comment on Linux 2.6.30: Hardware Assisted Time Stamping of Network Packets by Patrick Ohly

Patrick Ohly — Tue, 15 Sep 2009 15:55:41 +0000

Kate, SIOCSHWTSTAMP is not supported by the Linux kernel < 2.6.30, which explains the “Invalid argument” argument.

I can only guess about the “Operation not supported” error with 2.6.30: do you perhaps try to use the sf.net igb driver instead of the one that comes with 2.6.30? I am not sure whether (or which) sf.net releases support the HW time stamping API. This is a question that you should bring up on the sf.net/project/e1000 mailing list. These are also the people who continue to support the Linux kernel feature.

Comment on Linux 2.6.30: Hardware Assisted Time Stamping of Network Packets by Kate

Kate — Tue, 15 Sep 2009 14:17:43 +0000

I tried running ptpd -z linux_hw -b eth0 on the 2.6.30 kernel and got a different error:
net_tstamp SIOCSHWTSTAMP: Operation not supported

I do have the NIC 82576 card with an igb driver on my machine. Any ideas on what’s wrong?

Comments for SyncEvolution - The Missing Link

Comment on SyncML Client for KDE4 by rune

Comment on SyncEvolution Available for Nokia N810 by Synchronisationsgeschichten (3): Adressbuch synchronisieren | maemonews.de

Comment on Magic Tricks Revealed: How SyncML Works and When It Fails by Peter T

Comment on Linux 2.6.30: Hardware Assisted Time Stamping of Network Packets by Christopher Johnston

Comment on Linux 2.6.30: Hardware Assisted Time Stamping of Network Packets by Barry

Comment on SyncEvolution 0.9 released by Csaba Kokai

Comment on Running SyncEvolution as cron Job by edin

Comment on Linux 2.6.30: Hardware Assisted Time Stamping of Network Packets by Kate

Comment on Linux 2.6.30: Hardware Assisted Time Stamping of Network Packets by Patrick Ohly

Comment on Linux 2.6.30: Hardware Assisted Time Stamping of Network Packets by Kate