Skew too long - but only on 20+ sec long calls.

[Napalm]

P25RX + Bcalls. Every other call seems to upload fine but I get the occasional skew too long but only on calls lasting longer than about 20 seconds. I've seen a few just in the last hour or so.


Every other shorter call is accepted unless its already been captured by another node. I also dont have any skew issues on my other node 2800 which is running on the same PC.

Node 2819.

2023-10-17 01:40:52
Duration 18.1
Skew 15.632

2023-10-17 01:25:02
Duration: 20.2
Skew error was 17.654

2023-10-17 01:20:26
Duration 24.4
Skew error 20.894

2023-10-17 01:19:39
Duration 31.2
Skew 27.391

2023-10-17 01:01:07
Duration 23.6
Skew 21.638

 

[Napalm]

I cant edit but yes, my time is synced with ntp servers.

 

[belvdr]

I cant edit but yes, my time is synced with ntp servers.

How many servers are you configured for and are you configured to use pools? If only one, then you could still have time being off. However, it is odd you only receive this on longer duration calls.

 

[Napalm]

How many servers are you configured for and are you configured to use pools? If only one, then you could still have time being off. However, it is odd you only receive this on longer duration calls.

five different pool servers plus a bunch of other ones that are in the ntp config.

I have a cron job to manually force sync the time every hour and I had one this morning at 11:43:52. Call was 41.8 seconds skew was 39.064.

 

[belvdr]

five different pool servers plus a bunch of other ones that are in the ntp config.

I have a cron job to manually force sync the time every hour and I had one this morning at 11:43:52. Call was 41.8 seconds skew was 39.064.

Good config! For what it's worth, I've used both ntpd and chrony to sync time. Never had to force a sync. One thing I notice in your data is the skew is always within a few seconds of the call duration.

 

[belvdr]

Not that it will fix your issue, but I recommend chrony to replace ntpd. You can do things such as require a minimum number of sources that agree before updating your clock, like so (minsources parameter):

driftfile /var/lib/chrony/drift
leapsectz right/UTC
makestep 1.0 3
minsources 3
ntsdumpdir /var/lib/chrony
pool 0.pool.ntp.org iburst
pool 1.pool.ntp.org iburst
pool 2.pool.ntp.org iburst
pool 3.pool.ntp.org iburst
rtcsync

In this example, I require 3 sources agree, so time updates are reliable. Of course, always use at least 3 pools (not specific servers). Maybe @blantonl will chime in on a potential root cause.

 

[Napalm]

Thanks I'll look into chrony. The force sync was just to make sure.

And yes, the difference in time is anything from 2-5 seconds and I wonder if ffmpeg is causing the issue. It probably takes ffmpeg a few seconds to convert the file on a long call.

Just a theory.

 

[blantonl]

And yes, the difference in time is anything from 2-5 seconds and I wonder if ffmpeg is causing the issue. It probably takes ffmpeg a few seconds to convert the file on a long call.

Just a theory.

That might be it. You probably need a more powerful machine

 

[Napalm]

That might be it. You probably need a more powerful machine

Yeahhhhh you're right. I'm giving SDRTrunk all the RAM it needs and its tapping out at 1GB. I think more ram would help, though I see some folks are using 8 core processors smh.

 

[a417]

Yeahhhhh you're right. I'm giving SDRTrunk all the RAM it needs and its tapping out at 1GB. I think more ram would help, though I see some folks are using 8 core processors smh.

have you tried measuring utilization on this system when you get the long calls?
top? htop? glances?

Many options out there for this kind of thing.

 

[Napalm]

Its always in the logs, I haven't caught it live yet. I think I'll throw some more RAM at the linux box. 4GB isn't enough apparently.