Re: pvxs Access/list problem

[Heinz Junkes via Tech-talk <tech-talk@aps.anl.gov>]

Hello Andrew,
That's a good point. We used to always query NTP first to set the clock and only then start the NTP synchronisation mechanism.
Danke Heinz


> On 11. Nov 2025, at 18:39, Johnson, Andrew N. <anj@anl.gov> wrote:
> 
> Hello Heinz,
> 
> Is there some way to make the RTEMS NTP startup to do a jump synchronization on boot-up first, then start the slower ntpd sync process? The time synchronization approach that we’ve been using on VxWorks for a long time sets the clock as soon as it connects, and I've seen a similar configuration on some older embedded Linux systems. This is from one of our rc.local files:
> 
> #
> # Synchronize with time server
> #
> ntpclient -s -h timserv
> ntpclient -l -h timserv -q 400 >&/dev/null&
> 
> The first line above jumps the clock, the second line starts ntpd or its equivalent to maintain sync. I suspect this approach will prevent similar issues in other subsystems, so I’d like the EPICS code in RTEMS to do this if possible.
> 
> - Andrew
> 
> -- 
> Complexity comes for free, Simplicity you have to work for.
> 
> On 11/11/25, 10:48 AM, "Tech-talk" <tech-talk-bounces@aps.anl.gov> wrote:
> 
> Hi,
> It must have something to do with clock synchronization/NTP (that's my guess).
> Immediately after booting, when NTP is not yet synchronized, pvlist and pvget PV work, for example.
> 
> (base) hactar:~ junkes$ pvget my:custom:pv
> my:custom:pv <undefined>              42
> I'll take another look tomorrow.
> Danke Heinz
> 
> Begin forwarded message:
> 
> From: "Heinz Junkes \(FHI\) via Tech-talk" <tech-talk@aps.anl.gov>
> Subject: Re: pvxs Access/list problem
> Date: 11. November 2025 at 13:55:42 CET
> To: EPICS Tech-Talk <tech-talk@aps.anl.gov>
> Reply-To: "Heinz Junkes \(FHI\)" <junkes@fhi-berlin.mpg.de>
> 
> Hi,
> It seems to be an RTEMS issue. I have tested it extensively on Debian and OS X.
> Everything is going as expected. Sorry for the noise here.
> I need to take a look at what the problem is with RTEMS.
> Danke Heinz
> 
> 
> On 10. Nov 2025, at 21:07, Heinz Junkes via Tech-talk <tech-talk@aps.anl.gov> wrote:
> 
> HI,
> 
> 
> On 10. Nov 2025, at 17:17, Michael Davidsaver <mdavidsaver@gmail.com> wrote:
> 
> On 11/10/25 1:34 AM, Heinz Junkes (FHI) via Tech-talk wrote:
> Unfortunately, reading the PVs doesn't work either:
> ```
> (base) hactar:~ junkes$ env |grep EPICS_PVA
> EPICS_PVA_ADDR_LIST=141.14.128.12
> EPICS_PVA_AUTO_ADDR_LIST=NO
> (base) hactar:~ junkes$ pvget rtems:aiExample
> Timeout
> rtems:aiExample (base) hactar:~ junkes$ pvget my:custom:pv
> Timeout
> ```
> 
> Does anyone have any idea what I'm overlooking?
> Are you able to ping the IOC (141.14.128.12) from this host (141.14.128.70)?
> 
> (base) hactar:~ junkes$ ifconfig en0
> en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> options=50b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV,CHANNEL_IO>
> ether 38:f9:d3:09:e8:15
> inet6 fe80::14bb:5995:e241:143e%en0 prefixlen 64 secured scopeid 0x4
> inet 141.14.128.70 netmask 0xfffff000 broadcast 141.14.143.255
> nd6 options=201<PERFORMNUD,DAD>
> media: autoselect (1000baseT <full-duplex,flow-control>)
> status: active
> (base) hactar:~ junkes$ ping gonzo
> PING gonzo.rz-berlin.mpg.de (141.14.128.12): 56 data bytes
> 64 bytes from 141.14.128.12: icmp_seq=0 ttl=64 time=0.264 ms
> 64 bytes from 141.14.128.12: icmp_seq=1 ttl=64 time=0.295 ms
> 64 bytes from 141.14.128.12: icmp_seq=2 ttl=64 time=0.404 ms
> ^C
> --- gonzo.rz-berlin.mpg.de ping statistics ---
> 3 packets transmitted, 3 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 0.264/0.321/0.404/0.060 ms
> 
> 
> Can you connect to TCP 5076?  eg. with:
> 
> telnet 141.14.128.12 5075
> 
> (base) hactar:~ junkes$ telnet 141.14.128.12 5075
> Trying 141.14.128.12...
> Connected to 141.14.128.12.
> Escape character is '^]'.
> ���� anonymousca
> 
> 
> 
> 
> Also, you might setup a PVA link on this IOC with a distinctive PV name, then use 'pvxvct' on the host to look for those search broadcasts.
> 
> 
> rrtems@rtems-dev:~/MVME6100_7/EPICS/epics-support/pvxs/bin/linux-x86_64$ ./pvxget my:custom:pv
> Timeout with 1 outstanding
> 
> leads to :
> 
> rtems@rtems-dev:~/MVME6100_7/EPICS/epics-support/pvxs/bin/linux-x86_64$ ./pvxvct -P my:custom:pv
> 2025-11-10T21:05:52.932458937 INFO pvxvct 141.14.131.228:39384 Beacon 0x0d5dc20423f82d6367a9991d 141.14.131.228:42479
> 2025-11-10T21:05:56.103177244 INFO pvxvct 141.14.128.65:36209 Searching for:
> 2025-11-10T21:05:56.103207467 INFO pvxvct   "my:custom:pv"
> 2025-11-10T21:05:56.103213055 INFO pvxvct 10.1.2.3:36209 Searching for:
> 2025-11-10T21:05:56.103215518 INFO pvxvct   "my:custom:pv"
> 2025-11-10T21:05:56.291459974 INFO pvxvct 141.14.128.65:36209 Searching for:
> 2025-11-10T21:05:56.291488184 INFO pvxvct   "my:custom:pv"
> 2025-11-10T21:05:56.291494840 INFO pvxvct 10.1.2.3:36209 Searching for:
> 2025-11-10T21:05:56.291505468 INFO pvxvct   "my:custom:pv"
> 2025-11-10T21:06:03.523642481 INFO pvxvct 141.14.136.101:44036 Beacon 0x412ce9bbb99971c4925b7f98 141.14.136.101:5075
> 2025-11-10T21:06:04.212423500 INFO pvxvct 141.14.135.248:60008 Beacon 0x3d28c96800000000332cf600 141.14.135.248:5075
> ^C2025-11-10T21:06:05.395957864 INFO pvxvct Done
> 
> Danke, Heinz
> 
> 
> 
>