bryce-nakatani
commented
1 year ago The cause of my issue is that NTP updates my Edge node a millisecond or two ahead of UTC. It appears that for the Edge tests, NBIRTH and DBIRTH timestamps are allowed to be -300 to 0 seconds relative to UTC. This can be found in SessionEstablishmentTest.java (the constant is set in lines 600 and 817). In the payload tests, the timestamps are allowed to be -60 to +60 seconds relative to UTC (these comparisons use config.UTCwindow). Since all these timestamps are all sourced from the same clock, it might be nice to be consistent and allow the timestamps to be slightly ahead. If we're willing to have the timestamp as off as 300 seconds in the node and device births, perhaps accept timestamps to be -300 seconds to 300 seconds relative to UTC.
icraggs-sparkplug
What happened?
When running the Sparkplug 3.0.0 Released TCK, a test will randomly fail on a "payloads-nbirth-timestamp". When running a capture, the timestamp may be viewed in the Wireshark packet dissector. In the attached case, the timestamp appears to differ only by 1 millisecond (device ahead by 1 milliseconds) between the capture's UTC timestamp and the device's reported timestamp.
Similar failures occur on the dbirth timestamp test as well.
What is the product or software this issue was discovered with?
Released Sparkplug 3.0.0 TCK.
What exact steps need to be performed to reproduce the problem?
I've been able to replicate this behavior using the Tahu Edge Compatible Implementation from tahu 1.0.3 and my device under evaluation. This occurs whether the TCK runs on Ubuntu Server 22.04 with bare metal or Virtual Box (running on Windows 11) setup. The bare metal machine runs Adoptium JDK 11 and the VM is Ubuntu's standard openjdk-11-jdk.
Is this related to a Sparkplug Listing request? If so, link the issue from https://github.com/eclipse-sparkplug/sparkplug.listings here.
No response
Version
3.0.0 (Default)
Accept EFTL Terms