- 20 Sep, 2016 40 commits
-
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Here in ppsi, ./MAKEALL wrpc_defconfig wrpc_pdelay_defconfig shows a very small difference, but most pdelay code is then discarded by the wrpc-sw link time, due to --gc-sections. This is the result: laptopo% ./MAKEALL spec_defconfig spec_pdelay_defconfig ##### Building with 'spec_defconfig' /opt/lm32-gcc-4.5.3/bin/lm32-elf-ar: creating libsdbfs.a text data bss dec hex filename 87688 3492 6352 97532 17cfc wrc.elf ##### Building with 'spec_pdelay_defconfig' /opt/lm32-gcc-4.5.3/bin/lm32-elf-ar: creating libsdbfs.a text data bss dec hex filename 93140 3492 6360 102992 19250 wrc.elf What is missing now is the run-time choice between e2e and p2p. Later.... Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
There is a size problem in wrpc-sw, when built with SNMP inside, so some users, notably CERN, want to avoid the pdelay code (allegedly 7kB in the binary). Users who need pdelay don't actually run SNMP, so they don't have the size problem. This new setup allows a wrpc-sw without pdelay-related code. Wrpc with both mechanisms built in will be run-time configurable. the wrs and unix configurations for peer delay are removed, because for those architecture the choice is going to be performed at run time, in the configuration file. Please note that this commit is config-only, no code yet is there. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Using a data-driven approach to manage incoming frames is definitely cleaner and clearer. It even has a (very minor) size reduction for wrpc. I plan to use this approach overall, as time permits. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
This won't work, because packets must be sent to two different IP multicast addresses. This is not supported. The code being disabled had the effect of setting the pdelay destination for all frames, even for E2E runs. This fixes E2E UDP operation, leaving P2P broken as it was. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Davide Ciminaghi authored
If no follow-up is to be received, we trigger pp_servo_got_presp() on reception of peer delay response.
-
Davide Ciminaghi authored
In this case we also possibly have switch to port state to PASSIVE.
-
Davide Ciminaghi authored
A function should only do what it promises, so msg_unpack_header should just unpack. This move also gets also us ready for fixing compliance to 9.5.2.3.
-
Davide Ciminaghi authored
This gets us ready for leaving a state as a consequence of filtered out messages (9.5.2.3: discard announce AND switch state to PASSIVE).
-
Davide Ciminaghi authored
-
Davide Ciminaghi authored
-
Davide Ciminaghi authored
-
Davide Ciminaghi authored
-
Davide Ciminaghi authored
See Table 13. Note that we keep currentUtcOffset as it is and reset currentUtcOffsetValid, because we presently don't know about leap seconds. leap59 and leap61 are forced to zero.
-
Davide Ciminaghi authored
See Table 13.
-
Davide Ciminaghi authored
See Table 20.
-
Davide Ciminaghi authored
We don't support alternate masters at present.
-
Davide Ciminaghi authored
We're not a transparent clock, so this should be ok.
-
Davide Ciminaghi authored
-
Davide Ciminaghi authored
-
Davide Ciminaghi authored
-
Davide Ciminaghi authored
-
Davide Ciminaghi authored
-
Davide Ciminaghi authored
-
Davide Ciminaghi authored
We also avoid setting the same flag while handling a Pdelay_Resp_Followup.
-
Davide Ciminaghi authored
remove duplication, remove code size
-
Davide Ciminaghi authored
-
Davide Ciminaghi authored
11.3 d says: Upon receipt of the Delay_Resp message by the slave: 1) If the received Sync message indicated that a Follow_Up message will not be received, the <meanPathDelay> shall be computed as: <meanPathDelay> = [(t2 - t3) + (receiveTimestamp of Delay_Resp message - originTimestamp of Sync message) - correctionField of Sync message - correctionField of Delay_Resp message]/2. 2) If the received Sync message indicated that a Follow_Up message will be received, the <meanPathDelay> shall be computed as: <meanPathDelay> = [(t2 - t3) + (receiveTimestamp of Delay_Resp message - preciseOriginTimestamp of Follow_Up message) - correctionField of Sync message - correctionField of Follow_Up message - correctionField of Delay_Resp message]/2. We assume that: t1 = originTimestamp of Sync message (one step) or t1 = preciseOriginTimestamp of Follow_Up message (two steps) and t4 = receiveTimestamp of Delay_Resp message wich is true for masters not supporting sub-nanosecond timestamps (we don't support sub-ns precision via standard protocol, so the assumption should be true for us). As sync (or followup) arrives, we calculate m_to_s_dly, which is: t2 - t1 - cf_sync - cf_followup When delay_resp arrives, we calculate s_to_m_dly, which is: t4 - t3 - cf_delay_resp So [(m_to_s_dly + s_to_m_dly) / 2] should be equal to: (t2 - t3 + t4 - t1 - cf_sync - cf_followup - cf_delay_resp) / 2 which looks like the 11.3 d expression for mean path delay (note that cf_followup is zero for a one-step master). To get this result, we just save the delay_resp cf to ppi->cField.
-
Davide Ciminaghi authored
11.2 c says: If the twoStepFlag bit of the flagField of the of the Sync message is TRUE, indicating that a Follow_Up message will be received, then <offsetFromMaster> = <syncEventIngressTimestamp> - <preciseOriginTimestamp> - <meanPathDelay> - correctionField of Sync message - correctionField of Follow_Up message. Before this patch, only the correctionField of the Sync message was subtracted. We fix things by adding the Follow_Up correctionField to the Sync correctionField. Now m_to_s_dly as calculated in pp_servo_got_sync is: t2 - t1 - sync_cf - follow_up_cf
-
Davide Ciminaghi authored
-
Davide Ciminaghi authored
Before this commit, ANNOUNCE messages were sent with grandmaster-related fields equal to 0. Values for such fields were taken from the parentDS data set, which did not look properly initialized. Paragraphs 8.2.3.2 to 8.2.3.9 of the ieee1588 standard specify initialization values for the parentDS data set. Many such values come from the defaultDS, so care must be taken to initialize the parent data set __after__ the default data set. We do this in pp-initializing(). Signed-off-by: Davide Ciminaghi <ciminaghi@gnudd.com>
-
Alessandro Rubini authored
Please note that timeout_init is not resetting timeouts, it's just saving the values for later settings. Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-
Alessandro Rubini authored
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>
-