Re: pvxs Access/list problem

["Johnson, Andrew N. via Tech-talk" <tech-talk@aps.anl.gov>]

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