rpi4 as server?

I agree, you can do a lot if you try. The question remains, is this really the best and most sensible solution? Things that are simple and easy often are, those that require a lot of effort often aren't.

--




/ \  Mail | -- No unannounced, large, binary attachments, please! --

Depends.

If you need an accurate time on an RPi and it doesn't have a permanent, reliable connection to the internet but does have enough power to run a GPS receiver then using a GPS may well be the best choice. Or you could use one of the very low frequency time signals, e.g. MSF ('Rugby') or VVV, plug in a suitable receiver. If you use MSF then receivers are available from Galleon.

Equally, if you have a spare GPS receiver and want to experiment, using that becomes a nice, cheap solution.

OTOH, if there's a reasonably reliable internet connection where the Pi will be installed, use the NTP time service.

--
--   
Martin    | martin at 
Gregorie  | gregorie dot org

It does seem a bit OTT to use a GPS only to get the time. :-)

--
Chris Green

I don't think so, every navigation message includes a timestamp (only the time of week, not which week within the 1024 week cycle).

but you don't need the full almanac, or to know which space vehicle you're receiving from unless you want to know where you are.

of course.

But if you don't know where you are, you still don't know how old this timestamp is. You only know what the time was when the message was sent.

If you receive this message on Alpha Centauri, your clock is still 4,5 years slow. Fortunately the odds are you won't accidentally end up there without knowing, so the inaccuracy might be within your limits.

--
[J|O|R]

But every satellite sends a NAV message every 30 seconds, receive just one of those and you know the TOW (time of week)

I realise you need high time precision (a few tens of ns?) to calculate location based on distances from at least 4 satellites, but how imprecise is the single time stamp in each NAV message? sure you can't compensate for propagation delays etc between it and you, AIUI the message is timed to start on the :00 or:30 second mark by the satellite's atomic clock.

Assuming there are no rPi on other planets yet, it's safe to assume you're approximately 66ms away from the GPS satellites :-)

I'm far from certain that I've ever seen anything like that trickling out of the serial port of a Garmin GPS2 or GPS35 and its certainly not listed here:

or here:

so my guess is that its used internally by the receiver and never output as an NMEA message. As I said, the only time and date message listed is ZDA, which contains UTC, day, month, year and local time zone

--
--   
Martin    | martin at 
Gregorie  | gregorie dot org

No, I don't say it's spat out as NMEA sentences, it might be available in some of the chip-level GPS devices e.g. ublox seems to make TOW data available.

Seems the u-blox zed-f9t module claims

26s cold start (1 or 2s for restart) 5ns accuracy only requires a single satellite in view

whether it can meet all these individual specs at once, it doesn't say...

On Wed, 9 Dec 2020 12:22:54 +0000, Chris Green declaimed the following:

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

and:

--
Cheers, 
David 
Web: http://www.satsignal.eu

On 07/12/2020 17:06, Martin Gregorie wrote: ...

(OP)

output, just jittery nmea :-{

I did some tests a while ago checking the offsets between my local ntp/gps and network servers over many days. There was a systematic, IIRC diurnal, drift cycle. 10's of msec, no more, but unexplained.

There's also an unexplained step change after booting where the relative offsets of local gps and net servers shift by maybe 10 or so msec.

--
Mike Scott 
Harlow, England

Iptables is in the process of being replaced by nftables. I have a Pi with an nftables firewall, but so far I've only ported over my previous server iptables rules, I haven't explored further.

--
Joe

I added a MAC filter (previously ebtables) and it works fine on a pi3B.

--

-TV

Late to the party but my thoughts would be

Network on I386 is probably 100mb/s at best so will be the main bottle neck in your current set-up (actually network speeds are nearly always the bottle neck on a network server.) the pi has a 1000gb interface, IIRC it still cannot achieve full performance but it can achieve considerably more than 100mb/s.

therfore performance will be better than your current set-up even if it is not as good as a dedicated NAS

in a domestic environment how critical is this anyway?

as always it boils down to fast, reliable, cheap - choose any 2.

--
TAILFINS!! ... click ...

have you looked at the PiJuice hat?

4-6 hrs operation in default but can take larger batteries if req. also has an RTC on board so that fixes another of your problems.

--
Culture is the habit of being pleased with the best and knowing why.

^^^^^^ I wish !!! That should be 1Gb

You are out of date - Pi4 can do full gigabit and fill the pipe. Unlike previous Pi's it has native ethernet and seperate USB3 and 2. This is old news now.

or 3 if using a pi4 :-)

Quite, earlier in the thread I post that I was getting 110 MB/s from a network disk on a rpi4 4GB, 860 Samsung EVO, using Samba. That is near as damn it full Gigabit.

I just checked using CrystalDiskMark:

----------------------------------------------------------------------- CrystalDiskMark 6.0.2 x64 (C) 2007-2018 hiyohiyo Crystal Dew World :

-----------------------------------------------------------------------

• MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]

• KB = 1000 bytes, KiB = 1024 bytes

Sequential Read (Q= 32,T= 1) : 118.248 MB/s Sequential Write (Q= 32,T= 1) : 114.832 MB/s Random Read 4KiB (Q= 8,T= 8) : 51.672 MB/s [ 12615.2 IOPS] Random Write 4KiB (Q= 8,T= 8) : 33.194 MB/s [ 8104.0 IOPS] Random Read 4KiB (Q= 32,T= 1) : 46.954 MB/s [ 11463.4 IOPS] Random Write 4KiB (Q= 32,T= 1) : 34.565 MB/s [ 8438.7 IOPS] Random Read 4KiB (Q= 1,T= 1) : 6.425 MB/s [ 1568.6 IOPS] Random Write 4KiB (Q= 1,T= 1) : 6.543 MB/s [ 1597.4 IOPS]

Test : 1024 MiB [Y: 7.5% (34.4/457.4 GiB)] (x5) [Interval=5 sec] Date : 2020/12/13 10:20:14 OS : Windows 10 Professional [10.0 Build 19041] (x64)

Initially I had problems with my USB/PSU, but I replaced it with a mobile phone one and the rpi4 is now rock solid, all 3 as you say.