I'm contemplating replacing with a rpi4, which I gather is now supported
by freebsd, using a usb3 external hard drive. But is this likely to
prove slower or problematic for any other reason?
Hi all; a quick query about speeds.
I currently use an old i386 machine as home server (everything from
local NFS file-store, to bind, to email server). It's an acer aspire
r3700, running at 1.8GHz, 2 proc/4 thread job. It runs freebsd headless,
and I use vnc for day-to-day operations on it.
I'm contemplating replacing with a rpi4, which I gather is now supported
by freebsd, using a usb3 external hard drive. But is this likely to
prove slower or problematic for any other reason?
TIA for any thoughts.
--
Mike Scott
Harlow, England
The PIs are not great at I/O. They will do for a personal server with acouple
of users, but it is not ideal as a server platform.bus
II don'tknow about the newer PIs, but at least the early ones used an USB
for the ethernet connection, which meant network I/O was limited from the start.
Hi all; a quick query about speeds.
I currently use an old i386 machine as home server (everything from
local NFS file-store, to bind, to email server). It's an acer aspire
r3700, running at 1.8GHz, 2 proc/4 thread job. It runs freebsd headless,
and I use vnc for day-to-day operations on it.
I'm contemplating replacing with a rpi4, which I gather is now supported
by freebsd, using a usb3 external hard drive. But is this likely to
prove slower or problematic for any other reason?
derek.moody@casterbridge.net
Hi all; a quick query about speeds.
I currently use an old i386 machine as home server (everything from
local NFS file-store, to bind, to email server). It's an acer aspire
r3700, running at 1.8GHz, 2 proc/4 thread job. It runs freebsd headless,
and I use vnc for day-to-day operations on it.
I'm contemplating replacing with a rpi4, which I gather is now supported
by freebsd, using a usb3 external hard drive. But is this likely to
prove slower or problematic for any other reason?
The PIs are not great at I/O. They will do for a personal server with acouple
of users, but it is not ideal as a server platform.bus
II don'tknow about the newer PIs, but at least the early ones used an USB
for the ethernet connection, which meant network I/O was limited from the start.
Hi all; a quick query about speeds.
I currently use an old i386 machine as home server (everything from
local NFS file-store, to bind, to email server). It's an acer aspire
r3700, running at 1.8GHz, 2 proc/4 thread job. It runs freebsd headless,
and I use vnc for day-to-day operations on it.
I'm contemplating replacing with a rpi4, which I gather is now supported
by freebsd, using a usb3 external hard drive. But is this likely to
prove slower or problematic for any other reason?
TIA for any thoughts.
Your biggest problem will be deciding where to get your clock updates from; do you open the Pi to the internet or run a timeserver on another machine.
On 28/11/2020 11:33, Mike Scott wrote:
I currently use an old i386 machine as home server (everything fromYou really do not need a lot of power on a server that isn't running may applications. I suspect the bottleneck would be USB disk drive speed.
local NFS file-store, to bind, to email server). It's an acer aspire
r3700, running at 1.8GHz, 2 proc/4 thread job. It runs freebsd
headless, and I use vnc for day-to-day operations on it.
I'm contemplating replacing with a rpi4, which I gather is now
supported by freebsd, using a usb3 external hard drive. But is this
likely to prove slower or problematic for any other reason?
TIA for any thoughts.
Richard Falken <nospam.Richard.Falken@f1.n770.z5875.fidonet.org> wrote:
The PIs are not great at I/O. They will do for a personal server with a couple
of users, but it is not ideal as a server platform.
II don'tknow about the newer PIs, but at least the early ones used an USB bus
for the ethernet connection, which meant network I/O was limited from the
start.
Why post if you don't know. The Pi4 has a true 1 Gbps ethernet port and two usb 3.0 ports of 4.8 Gbps (what others now call usb 3.1 gen 1). This is possible because the new chip has PCIe (x1).
Also, get Fidonet to fix their clocks.
If your external drive is SSD it will be faster than your current server and can be arranged to run silently using much less power.
Caveat: I do not know the freebsd distro - I would expect it to be OK.
I use Raspup, the Puppy Linux version for Pi.
Your biggest problem will be deciding where to get your clock updates from; do you open the Pi to the internet or run a timeserver on another machine.
Hth, Cheerio,
On 28/11/2020 11:56, The Natural Philosopher wrote:
My Pi4 which I use as an NFS file server with a USB attached 2.5" hard
drive and it does about 100MB/s locally and 50MB/s over the network.
On 29/11/2020 08:15, A. Dumas wrote:
The Pi4 has a true 1 Gbps ethernet port and two
usb 3.0 ports of 4.8 Gbps (what others now call usb 3.1 gen 1). This is
possible because the new chip has PCIe (x1).
Thanks all for the comments. I've played with a pi3 (and earlier), but
it's clearly too slow even for my home network; I'm sort-of hoping a pi4 would be up to the job. Just a little pricey to buy and try yet another unless there's a real chance it'd be a go-er.
$ time /usr/bin/factor 1234567890123456789012345678901 1234567890123456789012345678901: 7742394596501 159455563099482401
real   0m2,086s
user   0m2,075s
sys   0m0,011s
On 01-12-2020 11:30, A. Dumas wrote:
$ time /usr/bin/factor 1234567890123456789012345678901
1234567890123456789012345678901: 7742394596501 159455563099482401
real   0m2,086s user   0m2,075s sys   0m0,011s
My 7 year old iMac (3.2 GHz quad i5) is only about 8x as fast:
$ time gfactor 1234567890123456789012345678901 1234567890123456789012345678901: 7742394596501 159455563099482401
real 0m0,257s user 0m0,248s sys 0m0,004s
(installed via MacPorts, then 'sudo port install coreutils')
On Tue, 01 Dec 2020 11:36:59 +0100, A. Dumas wrote:
On 01-12-2020 11:30, A. Dumas wrote:
$ time /usr/bin/factor 1234567890123456789012345678901
1234567890123456789012345678901: 7742394596501 159455563099482401
real   0m2,086s user   0m2,075s sys   0m0,011s
My 7 year old iMac (3.2 GHz quad i5) is only about 8x as fast:
$ time gfactor 1234567890123456789012345678901
1234567890123456789012345678901: 7742394596501 159455563099482401
real 0m0,257s user 0m0,248s sys 0m0,004s
(installed via MacPorts, then 'sudo port install coreutils')
Interesting: for exactly the same number to be factored I see:
System Real User Sys CPU
======
Lenovo T420 0.254s 0,252s 0.002s 1.9GHz Core i5
Lenovo R61i 0.702s 0.693s 0.006s 1.6GHz Core Duo
Whitebox PC 0.321s 0.314s 0.004s 1.0GHz AMC Dual Athlon
RPI 2B 21.995s 11.496s 0.040s
I'd been wondering whether an RP14B would be a good replacement for the
old AMD whitebox, but it looks as if a some sort of mini-ITX system would
be a better bet because I do all backups via rsync to a removable USB
drive connected to the old AMD system, and to do what I need it to do, a replacement would need a minimum of 4 USB ports plus SATA and a VGA-
capable display port.
Thanks for posting those numbers, though - doing so gave me the kick
needed to compare those speeds.
On Tue, 01 Dec 2020 11:36:59 +0100, A. Dumas wrote:
On 01-12-2020 11:30, A. Dumas wrote:
$ time /usr/bin/factor 1234567890123456789012345678901
1234567890123456789012345678901: 7742394596501 159455563099482401
real   0m2,086s user   0m2,075s sys   0m0,011s
My 7 year old iMac (3.2 GHz quad i5) is only about 8x as fast:
$ time gfactor 1234567890123456789012345678901 1234567890123456789012345678901: 7742394596501 159455563099482401
real 0m0,257s user 0m0,248s sys 0m0,004s
(installed via MacPorts, then 'sudo port install coreutils')
Interesting: for exactly the same number to be factored I see:
System Real User Sys CPU
======
Lenovo T420 0.254s 0,252s 0.002s 1.9GHz Core i5
Lenovo R61i 0.702s 0.693s 0.006s 1.6GHz Core Duo
Whitebox PC 0.321s 0.314s 0.004s 1.0GHz AMC Dual Athlon
RPI 2B 21.995s 11.496s 0.040s
I'd been wondering whether an RP14B would be a good replacement for the
old AMD whitebox, but it looks as if a some sort of mini-ITX system would
be a better bet because I do all backups via rsync to a removable USB
drive connected to the old AMD system, and to do what I need it to do, a replacement would need a minimum of 4 USB ports plus SATA and a VGA-
capable display port.
Why my Pi 2B is so much faster than yours I don't know, it's a Pi 2B
Revision 1.1.
However the real 'wow, that's a lot faster' thing for all of them was to
move from spinning disks to SSDs. (The t470 of course had one to start
with).
Martin Gregorie <martin@mydomain.invalid> wrote:
System Real User Sys CPU
======
Lenovo T420 0.254s 0,252s 0.002s 1.9GHz Core i5
Lenovo R61i 0.702s 0.693s 0.006s 1.6GHz Core Duo
Whitebox PC 0.321s 0.314s 0.004s 1.0GHz AMC Dual Athlon
RPI 2B 21.995s 11.496s 0.040s
Bear in mind that you're probably running a 32 bit RPi OS (on the Pi 2 you will be), and the PCs are probably running 64 bit binaries. That'll make a large difference to the speed of the arithmetic for this test.
System Real User Sys CPU
======
Lenovo T420 0.254s 0,252s 0.002s 1.9GHz Core i5
Lenovo R61i 0.702s 0.693s 0.006s 1.6GHz Core Duo
Whitebox PC 0.321s 0.314s 0.004s 1.0GHz AMC Dual Athlon
RPI 2B 21.995s 11.496s 0.040s
I'd been wondering whether an RP14B would be a good replacement for the
old AMD whitebox, but it looks as if a some sort of mini-ITX system would
be a better bet because I do all backups via rsync to a removable USB
drive connected to the old AMD system, and to do what I need it to do, a replacement would need a minimum of 4 USB ports plus SATA and a VGA-
capable display port.
Martin Gregorie <martin@mydomain.invalid> wrote:
System Real User Sys CPU ======
Lenovo T420 0.254s 0,252s 0.002s 1.9GHz Core i5 Lenovo R61i
0.702s 0.693s 0.006s 1.6GHz Core Duo Whitebox PC 0.321s 0.314s
0.004s 1.0GHz AMC Dual Athlon RPI 2B 21.995s 11.496s 0.040s
Bear in mind that you're probably running a 32 bit RPi OS (on the Pi 2
you will be), and the PCs are probably running 64 bit binaries. That'll
make a large difference to the speed of the arithmetic for this test.
Also to note that GNU Factor can be compiled to use libgmp, which has
custom assembler implementations of key functions. It appears the one
on Ubuntu 18.04 isn't compiled that way, but that could make a large difference in performance if different OSes are compiled different ways
(as well as the ARM v x86 comparison being different)
I don't think it's a particularly good benchmark to compare across architectures. And of course it's only single threaded.
I'd been wondering whether an RP14B would be a good replacement for the
old AMD whitebox, but it looks as if a some sort of mini-ITX system
would be a better bet because I do all backups via rsync to a removable
USB drive connected to the old AMD system, and to do what I need it to
do, a replacement would need a minimum of 4 USB ports plus SATA and a
VGA- capable display port.
That sounds like what you care about is I/O performance rather than CPU performance. Also bear in mind that mini ITXes are (mostly) a
completely different power class from the RPi. Horses for courses.
Compiling on the zero did however take about 20 times as long....
I don't think it's a particularly good benchmark to compare across architectures. And of course it's only single threaded.
RPi-4B 32bit   2.079s 2.075s 0.000s
RPi-4B 64bit   0.633s 0.627s 0.001s
Here's another number to try which should take about 10x as long:
$ time factor 101060998680964776859557640281323
$time factor 1234567890123456789012345678901
1234567890123456789012345678901: 7742394596501 159455563099482401
real    0m0.224s
user    0m0.220s
sys     0m0.000s
But on most CPU intensive  tasks the desktop is 4x faster than the server.
Compiling on the zero did however take about 20 times as long....
On 28/11/2020 11:56, The Natural Philosopher wrote:
On 28/11/2020 11:33, Mike Scott wrote:
I currently use an old i386 machine as home server (everything fromYou really do not need a lot of power on a server that isn't running
local NFS file-store, to bind, to email server). It's an acer aspire
r3700, running at 1.8GHz, 2 proc/4 thread job. It runs freebsd
headless, and I use vnc for day-to-day operations on it.
I'm contemplating replacing with a rpi4, which I gather is now
supported by freebsd, using a usb3 external hard drive. But is this
likely to prove slower or problematic for any other reason?
TIA for any thoughts.
may applications. I suspect the bottleneck would be USB disk drive speed.
It will still be quicker than the old PATA drives on a old 386 system.
My Pi4 which I use as an NFS file server with a USB attached 2.5" hard
drive and it does about 100MB/s locally and 50MB/s over the network.
On 01-12-2020 14:59, druck wrote:
RPi-4B 32bit   2.079s 2.075s 0.000s
RPi-4B 64bit   0.633s 0.627s 0.001s
Nice. Here's another number to try which should take about 10x as long:
$ time factor 101060998680964776859557640281323
It will still be quicker than the old PATA drives on a old 386
system.
My Pi4 which I use as an NFS file server with a USB attached 2.5"
hard drive and it does about 100MB/s locally and 50MB/s over the
network.
Mi rPi4 Samba file server using two USB attached drives gives:
SSD I get 345 MB/s local read, 110MB/s over the network read&write.
I get slightly slower than you for a very old laptop 2.5" HDD. 90 MB/s local, 45MB/s network.
Local was measured using hdparm.
I'm curious as to why the 2.5 HDD is only half speed over the network?
I got the T420 as a replacement for the old R61i and was going to sling
the latter when its disk (120GB) failed because its disk interface
hardware refused point blank to handle any disk of over 256GB, and by
that time you couldn't find any disks of less than 320GB capacity. But it >seemed a shame to bin it, so I fitted a 128GB Sandisk SSD and was amazed
by its performance for disk-related stuff. It still seems slow for
compiles etc, though, compared with the T420.
On 01/12/2020 16:16, A. Dumas wrote:
$ time factor 101060998680964776859557640281323
RPi-4B 32bit   28.093s 28.080s 0.004s Single core max 1.5GHz
RPi-4B 64bit   7.717s  7.713s  0.000s Single core max 1.5GHz
my Ubuntu 20.10 Desktop 64-bit seems consistently a little slower atDon't disregard the fact that the clock rate may be slightly different.
around 7.885s. Not doing anything else so I can't imagine it's
background tasks. Perhaps slightly different libraries or compiler
settings for factor?
Hi all; a quick query about speeds.....
I'm contemplating replacing with a rpi4, which I gather is now supported
by freebsd, using a usb3 external hard drive. But is this likely to
prove slower or problematic for any other reason?
TIA for any thoughts.
any suggestions for a good ups for a 24/7 pi server please?
On 04/12/2020 08:08, Mike Scott wrote:
any suggestions for a good ups for a 24/7 pi server please?
You could do worse than a continuously charged 11V lithium pack or 12v car battery and a 5V switched regulator.
How many amps does a Pi draw?
How long do you want it to stay up?
On 02-12-2020 11:17, druck wrote:
On 01/12/2020 16:16, A. Dumas wrote:
$ time factor 101060998680964776859557640281323
RPi-4B 32bit   28.093s 28.080s 0.004s Single core max 1.5GHz
RPi-4B 64bit   7.717s  7.713s  0.000s Single core max 1.5GHz
Wow, what a difference. I got ~exactly the same for RaspiOS 32-bit but
my Ubuntu 20.10 Desktop 64-bit seems consistently a little slower at
around 7.885s. Not doing anything else so I can't imagine it's
background tasks. Perhaps slightly different libraries or compiler
settings for factor? (checking) Well, the slower one on Ubuntu seems to
be newer at least, at version 8.32 vs. 8.30, ha!
After two brief power cuts in as many hours yesterday, which played
havoc with the existing machine(*), this looks like a project for the
new year, along with a ups - so any suggestions for a good ups for a
24/7 pi server please? A quick look round suggests I could pay nearly as
much as the pi would cost, so any ideas for something cheap(-ish) and reliable would be welcome.
"The Natural Philosopher" <tnp@invalid.invalid> wrote in message news:rqd0hr$r21$2@dont-email.me...
On 04/12/2020 08:08, Mike Scott wrote:
any suggestions for a good ups for a 24/7 pi server please?
You could do worse than a continuously charged 11V lithium pack or 12v
car battery and a 5V switched regulator.
How many amps does a Pi draw?
How long do you want it to stay up?
I happen to have a large battery that is charged from a 5 V USB charger (Micro USB input) and supplies 5 V (on a USB-A output). I thought I
could use this as a UPS - particularly to keep a Pi going for brief < 5 second power cuts that were plaguing our village (overhanging trees
touching the high voltage feed to a substation).
But sadly this battery cuts off its output as soon as either an input
cable is plugged in or 5V is supplied at that input (I forget which),
and this rather scuppers that plan. :-(
Your biggest problem will be deciding where to get your clock updates from; >> do you open the Pi to the internet or run a timeserver on another machine.
Buy an RTC addon for those times when it reboots, and setup NTPD on it, sync'ing from a couple of reliable internet timeservers. Then run the Pi
as your network time source.
My home serving Pi is setup like that. Not that the RTC addon is used
much, as my Pi only reboots once in half a dozen blue moons! I do sync
the RTC from the system even day - so it isn't out by much if it does
reboot, until it gets ntp sync. ntp maintained system time is far far
more accurate than any RTC
I used the AB electronics PiZero RTC
On 2020-11-29, Jim Jackson wrote:from;
Your biggest problem will be deciding where to get your clock updates
machine.do you open the Pi to the internet or run a timeserver on another
Buy an RTC addon for those times when it reboots, and setup NTPD on it, sync'ing from a couple of reliable internet timeservers. Then run the Pi
as your network time source.
My home serving Pi is setup like that. Not that the RTC addon is used
much, as my Pi only reboots once in half a dozen blue moons! I do sync
the RTC from the system even day - so it isn't out by much if it does reboot, until it gets ntp sync. ntp maintained system time is far far
more accurate than any RTC
I used the AB electronics PiZero RTC
Just out of curiosity, what significant benefits do you get from the
RTC? I have NTP running on mine, and the only anomaly I notice is
this sort of thing in the `last` output:
reboot system boot 5.4.79-v7l+ Thu Jan 1 01:00 still running
although `uptime` is correct and I can't find any '1970' or 'Jan' in
any of the greppable log files.
Adam Funk <a24061@ducksburg.com> wrote:
On 2020-11-29, Jim Jackson wrote:1st January 1970 is the "start of time" in the Unix world, that's why
Your biggest problem will be deciding where to get your clock updates from;
do you open the Pi to the internet or run a timeserver on another machine.
Buy an RTC addon for those times when it reboots, and setup NTPD on it,
sync'ing from a couple of reliable internet timeservers. Then run the Pi >> > as your network time source.
My home serving Pi is setup like that. Not that the RTC addon is used
much, as my Pi only reboots once in half a dozen blue moons! I do sync
the RTC from the system even day - so it isn't out by much if it does
reboot, until it gets ntp sync. ntp maintained system time is far far
more accurate than any RTC
I used the AB electronics PiZero RTC
Just out of curiosity, what significant benefits do you get from the
RTC? I have NTP running on mine, and the only anomaly I notice is
this sort of thing in the `last` output:
reboot system boot 5.4.79-v7l+ Thu Jan 1 01:00 still running
although `uptime` is correct and I can't find any '1970' or 'Jan' in
any of the greppable log files.
the next "millenium bug" is somewhere about 68 years from 1970 when a
signed 32-bit count of seconds runs out.
I was just wondering about
what kind of situation needs the external clock so the time is
accurate *before* NTP starts working.
On Mon, 07 Dec 2020 14:50:01 +0000 Adam Funk <a24061@ducksburg.com>
wrote:
I was just wondering about what kind of situation needs the external
clock so the time is accurate *before* NTP starts working.
It rather depends on how long might elapse before reaching a time server, if there's any danger of that being a long time then a RTC is
very helpful, if you're sure of a time server immediately after boot
then it's pretty much useless.
On 2020-12-07, Chris Green wrote:
Adam Funk <a24061@ducksburg.com> wrote:
On 2020-11-29, Jim Jackson wrote:1st January 1970 is the "start of time" in the Unix world, that's why
Your biggest problem will be deciding where to get your clock updates from;
do you open the Pi to the internet or run a timeserver on another machine.
Buy an RTC addon for those times when it reboots, and setup NTPD on it, >>>> sync'ing from a couple of reliable internet timeservers. Then run the Pi >>>> as your network time source.
My home serving Pi is setup like that. Not that the RTC addon is used
much, as my Pi only reboots once in half a dozen blue moons! I do sync >>>> the RTC from the system even day - so it isn't out by much if it does
reboot, until it gets ntp sync. ntp maintained system time is far far
more accurate than any RTC
I used the AB electronics PiZero RTC
Just out of curiosity, what significant benefits do you get from the
RTC? I have NTP running on mine, and the only anomaly I notice is
this sort of thing in the `last` output:
reboot system boot 5.4.79-v7l+ Thu Jan 1 01:00 still running
although `uptime` is correct and I can't find any '1970' or 'Jan' in
any of the greppable log files.
the next "millenium bug" is somewhere about 68 years from 1970 when a
signed 32-bit count of seconds runs out.
I understand why that's the magic reset date (which is why I was
grepping for "Jan" as well as "1970") --- I was just wondering about
what kind of situation needs the external clock so the time is
accurate *before* NTP starts working.
On 2020-11-29, Jim Jackson wrote:
I used the AB electronics PiZero RTC
Just out of curiosity, what significant benefits do you get from the
RTC? I have NTP running on mine, and the only anomaly I notice is
this sort of thing in the `last` output:
reboot system boot 5.4.79-v7l+ Thu Jan 1 01:00 still running
although `uptime` is correct and I can't find any '1970' or 'Jan' in
any of the greppable log files.
The classic ntpd does not like to sync with a time that is
far off from the local time. I used ntpdate to set the local
time before starting ntpd up.
The classic ntpd does not like to sync with a time that is
far off from the local time. I used ntpdate to set the local
time before starting ntpd up.
Yeah I used to do that, but ntpd now has the -g option to allow it do an initial time jump, so ntpdate is no longer needed.
On 2020-12-07, Adam Funk <a24061@ducksburg.com> wrote:
On 2020-11-29, Jim Jackson wrote:
I used the AB electronics PiZero RTC
Just out of curiosity, what significant benefits do you get from the
RTC? I have NTP running on mine, and the only anomaly I notice is
this sort of thing in the `last` output:
reboot system boot 5.4.79-v7l+ Thu Jan 1 01:00 still running
although `uptime` is correct and I can't find any '1970' or 'Jan' in
any of the greppable log files.
My home server is a syslog server for other stuff - like the VDSL router
and Wireless access points - so I like it to have a reasonably good time
as soon into boot as possible, even if it has only booted a handfull of
times in the last couple of years. Also if the house power goes, then
when it comes back, the server will come back well before the router
gets DSL sync and an internet connection - and it's time will be good
until internet connectivity is resumed.
Several years ago we had several incidents where power would go (all our street) for 30 secs or so and then return. It turned out there was
something dodgy under a road - and an especially heavy lorry in the
wrong part of the road would cause problems. The road was up for quite a while as they fixed it.
My home server is a syslog server for other stuff - like the VDSL router[]
and Wireless access points - so I like it to have a reasonably good time
as soon into boot as possible, even if it has only booted a handfull of
times in the last couple of years. Also if the house power goes, then
when it comes back, the server will come back well before the router
gets DSL sync and an internet connection - and it's time will be good
until internet connectivity is resumed.
On Mon, 07 Dec 2020 15:55:32 +0000, Ahem A Rivet's Shot wrote:
It rather depends on how long might elapse before reaching a time server, if there's any danger of that being a long time then a RTC is
very helpful, if you're sure of a time server immediately after boot
then it's pretty much useless.
Don't forget that an old GPS unit, provided it has serial NMEA0183 output which many of them had, can be used by ntpd as a primary time reference. These can be connected to an RPI via a USB-serial adapter. There is a reference driver for ntpd that allows it to accept an NMEA0183 primary
time stream.
How long with a GPS unit take to get a time fix from cold, out of interest?
How long with a GPS unit take to get a time fix from cold, out of
interest?
The OP's situation sounds like one where a RTC would be quicker than a
cold GPS, although maybe there's a way to get a time out of GPS before
it has seen enough satellites for a position fix.
(and can you do A-GPS by configuring the lat/long of your stationary
Pi?)
Just out of curiosity, what significant benefits do you get from the
RTC? I have NTP running on mine, and the only anomaly I notice is
this sort of thing in the `last` output:
reboot system boot 5.4.79-v7l+ Thu Jan 1 01:00 still running
although `uptime` is correct and I can't find any '1970' or 'Jan' in
any of the greppable log files.
Theo wrote:
How long with a GPS unit take to get a time fix from cold, out of
interest?
That depends on the make, model, how good its view of the sky is and how
long since it last had a fix.
Martin Gregorie wrote:
Theo wrote:
How long with a GPS unit take to get a time fix from cold, out of
interest?
That depends on the make, model, how good its view of the sky is and how
long since it last had a fix.
I think Theo was only asking about a time fix, not a location fix.
Martin Gregorie wrote:
Theo wrote:
How long with a GPS unit take to get a time fix from cold, out of
interest?
That depends on the make, model, how good its view of the sky is and
how long since it last had a fix.
I think Theo was only asking about a time fix, not a location fix.
On Mon, 07 Dec 2020 15:55:32 +0000, Ahem A Rivet's Shot wrote:
On Mon, 07 Dec 2020 14:50:01 +0000 Adam Funk <a24061@ducksburg.com>
wrote:
I was just wondering about what kind of situation needs the external
clock so the time is accurate *before* NTP starts working.
It rather depends on how long might elapse before reaching a time
server, if there's any danger of that being a long time then a RTC is
very helpful, if you're sure of a time server immediately after boot
then it's pretty much useless.
Don't forget that an old GPS unit, provided it has serial NMEA0183 output which many of them had, can be used by ntpd as a primary time reference. These can be connected to an RPI via a USB-serial adapter. There is a reference driver for ntpd that allows it to accept an NMEA0183 primary
time stream.
On 2020-12-07, Martin Gregorie wrote:
On Mon, 07 Dec 2020 15:55:32 +0000, Ahem A Rivet's Shot wrote:
On Mon, 07 Dec 2020 14:50:01 +0000 Adam Funk <a24061@ducksburg.com>
wrote:
I was just wondering about what kind of situation needs the external
clock so the time is accurate *before* NTP starts working.
It rather depends on how long might elapse before reaching a time
server, if there's any danger of that being a long time then a RTC is
very helpful, if you're sure of a time server immediately after boot
then it's pretty much useless.
Don't forget that an old GPS unit, provided it has serial NMEA0183
output which many of them had, can be used by ntpd as a primary time
reference. These can be connected to an RPI via a USB-serial adapter.
There is a reference driver for ntpd that allows it to accept an
NMEA0183 primary time stream.
(Not that I need something like this, but it's interesting.)
I don't think an old GPS unit would be able to get a signal in my
"network cupboard", which is a shelf in the back of a wardrobe under the stairs from the 1st to 2nd floors, & not on an outside wall.
get a signal in my "network cupboard",Modern receivers are much more sensitive.
On Wed, 09 Dec 2020 10:35:11 +0000, Adam Funk wrote:
On 2020-12-07, Martin Gregorie wrote:
On Mon, 07 Dec 2020 15:55:32 +0000, Ahem A Rivet's Shot wrote:
On Mon, 07 Dec 2020 14:50:01 +0000 Adam Funk <a24061@ducksburg.com>
wrote:
I was just wondering about what kind of situation needs the external >>>>> clock so the time is accurate *before* NTP starts working.
It rather depends on how long might elapse before reaching a time
server, if there's any danger of that being a long time then a RTC is
very helpful, if you're sure of a time server immediately after boot
then it's pretty much useless.
Don't forget that an old GPS unit, provided it has serial NMEA0183
output which many of them had, can be used by ntpd as a primary time
reference. These can be connected to an RPI via a USB-serial adapter.
There is a reference driver for ntpd that allows it to accept an
NMEA0183 primary time stream.
(Not that I need something like this, but it's interesting.)
I don't think an old GPS unit would be able to get a signal in my
"network cupboard", which is a shelf in the back of a wardrobe under the
stairs from the 1st to 2nd floors, & not on an outside wall.
The older ones often don't work in a house, and sometimes not in a forest either, let alone under a tin roof. Modern receivers are much more
sensitive. I've just fired two GPS receivers up to prove this point:
- My old (1990) Garmin GPS2+ had no signal at all in the sill of a South- facing window and had problems outside it as well, due mainly to the sky
view being restricted by both the house behind me and (bare) trees on the other three sides. It did eventually find two satellites, but never determined where it was.
- My more recent (2014) Medion S3747 PNA got enough signal on the window
sill to set its clock, but couldn't see enough satellites to determine
its position. However, when it was taken outside to the same point as the GPS2+ it was able to determine its location and altitude after around 2 minutes.
Martin Gregorie wrote:
get a signal in my "network cupboard",Modern receivers are much more sensitive.
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.
Martin Gregorie wrote:
get a signal in my "network cupboard",Modern receivers are much more sensitive.
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.
Andy Burns wrote:
I think Theo was only asking about a time fix, not a location fix.
It does not matter - time and coordinates are members of the same
equation group which has to be solved to get any of the members.
The ephemerides data comes pretty slowly, it will take several minutes
to get them if the receiver is out of date.
A decent net connection and NTP will get the time much faster.
I don't think that affects a GPS receiver's startup process: it
still needs the almanac data to determine the exact time:
its location
matters to it when correcting for signal travel time from satellite to receiver and, if any satellite clocks have been reset recently, what
their UTC offset is now.
If the receiver hasn't been run for a while it
will need an updated almanac and, as Andy said, it may have to wait up to 12.5 minutes for this to be retransmitted.
If a GPS receiver is designed to be a time source, it will emit NMEA-0183
ZDA messages which only contain UTC date/time information, but equally there's no reason why the time recipient shouldn't accept NMEA-0183
message types RMC, GGA or GNS and discard everything except the time
field because all these messages contain a UTC time stamp accurate to 10
mS.
It does not matter - time and coordinates are members of the sameI don't think so, every navigation message includes a timestamp
equation group which has to be solved to get any of the members.
Martin Gregorie wrote:
I don't think that affects a GPS receiver's startup process: it still
needs the almanac data to determine the exact time:
But every satellite sends a NAV message every 30 seconds, receive just
one of those and you know the TOW (time of week)
Andy Burns wrote:
But every satellite sends a NAV message every 30 seconds, receive justI'm far from certain that I've ever seen anything like that trickling out
one of those and you know the TOW (time of week)
of the serial port of a Garmin[...]
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
Andy Burns wrote:
every navigation message includes a timestamp
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.
it might be available in some of the chip-level GPS devices e.g. ublox
It does seem a bit OTT to use a GPS only to get the time. :-)
On Wed, 9 Dec 2020 12:22:54 +0000, Chris Green <cl@isbd.net> declaimed the following:
It does seem a bit OTT to use a GPS only to get the time. :-)
https://timemachinescorp.com/product/gps-time-server-tm1000a/
Don't forget that an old GPS unit, provided it has serial NMEA0183 output which many of them had, can be used by ntpd as a primary time reference. These can be connected to an RPI via a USB-serial adapter. There is a reference driver for ntpd that allows it to accept an NMEA0183 primary
time stream.
On 29/11/2020 02:28, Derek.Moody wrote:
.....
If your external drive is SSD it will be faster than your current
server and can be arranged to run silently using much less power.
Caveat: I do not know the freebsd distro - I would expect it to be
OK. I use Raspup, the Puppy Linux version for Pi.
I've had fbsd running on the pi3, an unsupported 12.x. Actually, I'd seriously consider switching to a linux, except that I'm doing things
using pf that don't seem readily possible with iptables (although
maybe I've missed something).
On Tue, 1 Dec 2020 08:54:14 +0000
Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
On 29/11/2020 02:28, Derek.Moody wrote:Iptables is in the process of being replaced by nftables. I have a Pi
.....
If your external drive is SSD it will be faster than your current
server and can be arranged to run silently using much less power.
Caveat: I do not know the freebsd distro - I would expect it to be
OK. I use Raspup, the Puppy Linux version for Pi.
I've had fbsd running on the pi3, an unsupported 12.x. Actually, I'd
seriously consider switching to a linux, except that I'm doing things
using pf that don't seem readily possible with iptables (although
maybe I've missed something).
with an nftables firewall, but so far I've only ported over my previous server iptables rules, I haven't explored further.
Hi all; a quick query about speeds.
I currently use an old i386 machine as home server (everything from
local NFS file-store, to bind, to email server). It's an acer aspire
r3700, running at 1.8GHz, 2 proc/4 thread job. It runs freebsd headless,
and I use vnc for day-to-day operations on it.
I'm contemplating replacing with a rpi4, which I gather is now supported
by freebsd, using a usb3 external hard drive. But is this likely to
prove slower or problematic for any other reason?
TIA for any thoughts.
On 28/11/2020 11:33, Mike Scott wrote:
Hi all; a quick query about speeds.....
I'm contemplating replacing with a rpi4, which I gather is now
supported by freebsd, using a usb3 external hard drive. But is this
likely to prove slower or problematic for any other reason?
TIA for any thoughts.
Many thanks to all who've replied.
After two brief power cuts in as many hours yesterday, which played
havoc with the existing machine(*), this looks like a project for the
new year, along with a ups - so any suggestions for a good ups for a
24/7 pi server please? A quick look round suggests I could pay nearly as
much as the pi would cost, so any ideas for something cheap(-ish) and reliable would be welcome.
Thanks.
(*) Weird things happened: it hung twice while trying to reboot, then rebooted on the 3rd try: but fsck moaned about sundry files, even though
the ufs file system is journalled.
On Sat, 28 Nov 2020 11:33:09 +0000, Mike Scott wrote:^^^^^^ I wish !!! That should be 1Gb
Hi all; a quick query about speeds.
I currently use an old i386 machine as home server (everything from
local NFS file-store, to bind, to email server). It's an acer aspire
r3700, running at 1.8GHz, 2 proc/4 thread job. It runs freebsd headless,
and I use vnc for day-to-day operations on it.
I'm contemplating replacing with a rpi4, which I gather is now supported
by freebsd, using a usb3 external hard drive. But is this likely to
prove slower or problematic for any other reason?
TIA for any thoughts.
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.
On 2020-12-12, alister <alister.ware@ntlworld.com> wrote:
On Sat, 28 Nov 2020 11:33:09 +0000, Mike Scott wrote:^^^^^^ I wish !!! That should be 1Gb
Hi all; a quick query about speeds.
I currently use an old i386 machine as home server (everything from
local NFS file-store, to bind, to email server). It's an acer aspire
r3700, running at 1.8GHz, 2 proc/4 thread job. It runs freebsd headless, >>> and I use vnc for day-to-day operations on it.
I'm contemplating replacing with a rpi4, which I gather is now supported >>> by freebsd, using a usb3 external hard drive. But is this likely to
prove slower or problematic for any other reason?
TIA for any thoughts.
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.
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.
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.
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.
On 2020-12-12, alister <alister.ware@ntlworld.com> wrote:
On Sat, 28 Nov 2020 11:33:09 +0000, Mike Scott wrote:^^^^^^ I wish !!! That should be 1Gb
Hi all; a quick query about speeds.
I currently use an old i386 machine as home server (everything from
local NFS file-store, to bind, to email server). It's an acer aspire
r3700, running at 1.8GHz, 2 proc/4 thread job. It runs freebsd
headless,
and I use vnc for day-to-day operations on it.
I'm contemplating replacing with a rpi4, which I gather is now
supported by freebsd, using a usb3 external hard drive. But is this
likely to prove slower or problematic for any other reason?
TIA for any thoughts.
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.
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.
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.
or 3 if using a pi4 :-)
Ok I stand corrected on network performace.
but that just simply confirms my main point that the data network is the major bottle neck not the server platform, so Pi performance is not
critical & it will be easily up to the task in this setup.
With servers it is almost always the IO speed that dominates - disk IO
or network IO - there is the square root of sweet fanny adam's amount of computing power done in serving files.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 293 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 213:32:33 |
| Calls: | 6,619 |
| Calls today: | 1 |
| Files: | 12,168 |
| Messages: | 5,317,428 |