Re: ntp problems stratum 2 to 14?
On Thu, 27 Feb 2020 at 06:43, Peter Jeremy wrote:
> On 2020-Feb-26 16:37:43 +1100, Dewayne Geraghty
> wrote:
> >I usually run ntpd with both aslr and as user ntpd. While testing I
> >noticed that my server with a direct network cable to my main time keeper,
> >jumped from the expected stratum 2 to 14 as follows (I record the date so
> I
> >can synch with the debug log, also below):
> >
> >vm.loadavg={ 0.09 0.10 0.18 }
> >
> >Wed 26 Feb 2020 15:16:38 AEDT
> > remote refid st t when poll reach delay offset
> > jitter
>
> >==
> > 10.0.7.6203.35.83.2422 u 44 64 3770.147 -227.12
> 33.560
> >*127.127.1.1 .LOCL. 14 l 59 128 3770.0000.000
> 0.000
>
> >26 Feb 15:03:40 ntpd[8772]: LOCAL(1) 901a 8a sys_peer <== bad
>
> Why is this bad? You've specified that this is a valid clock source so
> ntpd is free to use it if it decides it is the best source of time.
>
> >server 127.127.1.1 minpoll 7 maxpoll 7
> >fudge 127.127.1.1 stratum 14
>
> Synchronizing to the local clock (ie using 127.127.1.x as a reference) is
> almost never correct. What external (to NTP) source is being used to
> synchronize the local clock?
>
> >I'm also very surprised that the jitter on the server (under testing) is
> so
> >poor. The internet facing time server is
> >*x.y.z.t .ATOM. 1 u 73 5127 23.776 34.905 95.961
> >but its very old and not running aslr.
>
> The 23ms distance to the peer suggests that this is over the Internet.
> What
> sort of link do you have to the Internet and how heavily loaded is it? The
> NTP protocol includes the assumption that the client-server path delay is
> symmetric - this is often untrue for SOHO connections. And SOHO
> connections
> will often wind up saturated in one direction - which skews the apparent
> timestamps and shows up as high jitter values.
>
> > /usr/local/sbin/ntpd -c /etc/ntp.conf -g -g -u ntpd --nofork
> ...
> >I get similar results with /usr/sbin/ntpd, I've been testing both and
> >happened to record details for the port ntpd.
>
> It's probably not relevant but it would be useful for you to say up front
> which ntpd you are having problems with and which version of the port you
> have installed.
>
> --
> Peter Jeremy
>
Hi Peter, I appreciate your thoughts. Yes, using LOCL is bad because it
should only be used when the stratum 2 machine is unavailable, and it isn't
(representative ping time average 0.15ms). The load is less than 10% on
both devices and both the internet and internal traffic is typically less
than 50Kb. :/
The use of LOCL clock was a fix as named failed if ntpd only used the
timeserver and it lost sync (due to some ipsec work another story), I
suspect kerberos had a part as it uses tkey-gssapi-keytab. I should
investigate why the use of LOCL clock makes things work, but ... its a
workaround and I'm ok with it.
I'm at my wits end, I've systematically changed one variable from the list,
and always the system clock reverts to LOCL within 20 minutes if not
immediately. This is FreeBSD 12.1-STABLE #0 r356046M: Tue Dec 24. I think
its time to try an earlier ntp to see if that helps (???) :(
The variables tested, one changed at a time:
- security.mac.ntpd.enabled
- kern.elf64.aslr.enable kern.elf64.aslr.stack_gap changed as a pair
- security.mac.portacl.rules
- run as root or ntpd
- use of proccontrol (which was changed with different combinations of
aslr, stack_gap
- all off and run as root
- and of course changes to the command line (-g or -G or -g -x)
I guess everyone else is using ntpd without a problem? (or not...)
Cheers, Dewayne
PS Apologies for delay in getting back, gmail placed your reply in the spam
folder :/
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Running FreeBSD on M.2 SSD
On 2020-02-27 20:44, Mario Olofo wrote: Thanks for the update. May you share what quirks was detected for your card and firmware to see if it matches mine? The only way I was able to run FreeBSD 12-STABLE on the SSD was using the suggested sysctl vfs.zfs.trim.enabled=0 Maybe the problem really is a combination of factors, for the person that filed a bug on bugzilla the fix was setting the quirks 4k and broken_trim, but for me the real block size is 512bytes and only setting the flag broken_trim didn't help... This is a default install off of the latest 12.1-STABLE snapshot, no special loader or sysctl knobs used. dmesg doesn't show anything interesting: $ dmesg|grep ada ses0: pass0,ada0 in 'Slot 00', SATA Slot: scbus0 target 0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device ada0: Serial Number 185243800880 ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada0: Command Queueing enabled ada0: 457872MB (937721856 512 byte sectors) GEOM_ELI: Device ada0p4.eli created. here's the output of sysctl: $ sysctl kern.cam.ada kern.cam.ada.0.sort_io_queue: 0 kern.cam.ada.0.max_seq_zones: 0 kern.cam.ada.0.optimal_nonseq_zones: 0 kern.cam.ada.0.optimal_seq_zones: 0 kern.cam.ada.0.zone_support: None kern.cam.ada.0.zone_mode: Not Zoned kern.cam.ada.0.rotating: 0 kern.cam.ada.0.unmapped_io: 1 kern.cam.ada.0.write_cache: -1 kern.cam.ada.0.read_ahead: -1 kern.cam.ada.0.delete_method: DSM_TRIM kern.cam.ada.write_cache: 1 kern.cam.ada.read_ahead: 1 kern.cam.ada.spindown_suspend: 1 kern.cam.ada.spindown_shutdown: 1 kern.cam.ada.send_ordered: 1 kern.cam.ada.default_timeout: 30 kern.cam.ada.retry_count: 4 cheers, -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Running FreeBSD on M.2 SSD
Hello Mario I am sorry, my comment contains no help for your case, but is treading my problems with FreeBSD in the past. Am Fr, 28.02.2020, 04:58 schrieb Pete Wright: >> root@~ # camcontrol devlist         at >> scbus0 target 0 lun 0 >> (ada0,pass0) >>  at scbus1 target 0 lun 0 (ada1,pass1) > just wanted to provide an update here. so i had a system that needed a new > root drive and > figured that the price of this device was worth a shot. i figured if it has > issues it'd be a > good opportunity to help find the root cause and fix them. so anyway...i > got the drive today and > i am not seeing any issues with it so far. here's the device on my end: > > so i don't think it's an issue with this specific m.2 device, perhaps there > is something odd > happening in your local env though that is causing this issue to crop up. The first Motherboard was an ASUS SP3G with FreeBSD 2.2.5, quriks in IO, depending on failures of the onBoard implementation of the SCSI-NCR, fixed by Stefan Esser. A few years later, my system crashes when compiling the world, sometimes after 30minutes, sometimes 32min... everytime on another place in the source... Reason was a fan for one of my two "hot" Seagate Barracudas, he won't spin anymore, he was "baken". My Powersupply was big, but if compiling, after the time, the baken fan empties the ELKOS of the Power and cause the reset... I've learned: FreeBSD is a great stable system, all my issues found the reason in other places in over 25years of using. OK, it seems, that it is a little bit intolerant to other issues or mad hardware :D... Bye Stefan ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Running FreeBSD on M.2 SSD
Thanks for the update. May you share what quirks was detected for your card and firmware to see if it matches mine? The only way I was able to run FreeBSD 12-STABLE on the SSD was using the suggested sysctl vfs.zfs.trim.enabled=0 Maybe the problem really is a combination of factors, for the person that filed a bug on bugzilla the fix was setting the quirks 4k and broken_trim, but for me the real block size is 512bytes and only setting the flag broken_trim didn't help... Mario Em sex., 28 de fev. de 2020 às 00:58, Pete Wright escreveu: > > > On 2/24/20 11:13 AM, Mario Olofo wrote: > > Hi Pete, > > The nvmecontrol devlist don't found any devices. > pciconf -lv nvme0 didn't found anything either. > > The camcontrol devlist output was as follows: > > root@~ # camcontrol devlist > at scbus0 target 0 lun 0 (ada0,pass0) > at scbus1 target 0 lun 0 (ada1,pass1) > at scbus2 target 0 lun 0 (pass2,da0) > > > just wanted to provide an update here. so i had a system that needed a > new root drive and figured that the price of this device was worth a shot. > i figured if it has issues it'd be a good opportunity to help find the root > cause and fix them. so anyway...i got the drive today and i am not seeing > any issues with it so far. here's the device on my end: > > $ sudo camcontrol devlist > at scbus0 target 0 lun 0 (ada0,pass0) >at scbus2 target 0 lun 0 (ses0,pass1) > $ > > i am running 12-STABLE, with an encrypted zfsroot device. i've pumped > about 10gigs through it so far restoring my homedir with no issues, and zfs > scrub has run without any corrupted blocks detected. > > so i don't think it's an issue with this specific m.2 device, perhaps > there is something odd happening in your local env though that is causing > this issue to crop up. > > -pete > > -- > Pete wrightp...@nomadlogic.org > @nomadlogicLA > > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Running FreeBSD on M.2 SSD
On 2/24/20 11:13 AM, Mario Olofo wrote: Hi Pete, The nvmecontrol devlist don't found any devices. pciconf -lv nvme0 didn't found anything either. The camcontrol devlist output was as follows: root@~ # camcontrol devlist at scbus0 target 0 lun 0 (ada0,pass0) at scbus1 target 0 lun 0 (ada1,pass1) at scbus2 target 0 lun 0 (pass2,da0) just wanted to provide an update here. so i had a system that needed a new root drive and figured that the price of this device was worth a shot. i figured if it has issues it'd be a good opportunity to help find the root cause and fix them. so anyway...i got the drive today and i am not seeing any issues with it so far. here's the device on my end: $ sudo camcontrol devlist at scbus0 target 0 lun 0 (ada0,pass0) at scbus2 target 0 lun 0 (ses0,pass1) $ i am running 12-STABLE, with an encrypted zfsroot device. i've pumped about 10gigs through it so far restoring my homedir with no issues, and zfs scrub has run without any corrupted blocks detected. so i don't think it's an issue with this specific m.2 device, perhaps there is something odd happening in your local env though that is causing this issue to crop up. -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Running FreeBSD on M.2 SSD
Hello Daniel, Indeed setting the sysctl variable on install and after that on loader.conf appears to solve the data corruption problem =O Did the same as before, install git, node, npm, etc and all good. I will build the kernel and install xorg and xfce to use more disk space and see if some problem shows up Thank you, Mario Em qui., 27 de fev. de 2020 às 10:41, Daniel Kalchev escreveu: > Like I wrote earlier: > > sysctl vfs.zfs.trim.enabled=0 > > is your friend. > > Best to do this before installing and put vfs.zfs.trim.enabled=0 in > /boot/loader.conf in the boot drive to permanently have it. > > Daniel > > > On 27 Feb 2020, at 14:19, Mario Olofo wrote: > > > > This was supposed to be disabled by the quirk 0x02 > (ADA_Q_NCQ_TRIM_BROKEN) > > right? > > There's some command to disable trim on installer boot and then > permanently > > after the install? > > > > Mario > > > > > > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Running FreeBSD on M.2 SSD
On 2020-02-26 22:54, Mario Olofo wrote: Hello Mark, Yes, I think that it's related to the WD Green SSD. Today I found this bug on FreeBSD's bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225666 Tried to reinstall and recompile the kernel with the patch but it didn't work, I continue to see corrupted data. I think that the only way to be really sure about the corrupted data is to reinstall again but already boot with the quirks configured, but the kern.cam.ada.X.quirks don't seems to exists on FreeBSD 12, so I have a probability of corruption between installation and compilation of the patched kernel... Don't know what more to do... Mario Hi, please forgive my lack of experience with ZFS, but with regard to buggy SATA something hasn't been brought up yet: If ZFS is sitting on top of GPT, what sectorsize and offset are used? What blocksize is "native" to the drive? Are these aligned? I recall this chance for misalignment being a cause of silent write corruption after installing a new SSD for Apple MacOS; maybe FreeBSD ZFS on SATA happens to be similarly susceptible. Theron ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Running FreeBSD on M.2 SSD
This was supposed to be disabled by the quirk 0x02 (ADA_Q_NCQ_TRIM_BROKEN) right? There's some command to disable trim on installer boot and then permanently after the install? Mario Em qui., 27 de fev. de 2020 às 01:20, Warner Losh escreveu: > > > On Wed, Feb 26, 2020, 8:54 PM Mario Olofo wrote: > >> Hello Mark, >> >> Yes, I think that it's related to the WD Green SSD. >> Today I found this bug on FreeBSD's bugzilla: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225666 >> >> Tried to reinstall and recompile the kernel with the patch but it didn't >> work, I continue to see corrupted data. >> I think that the only way to be really sure about the corrupted data is to >> reinstall again but already boot with the quirks configured, but the >> kern.cam.ada.X.quirks don't seems to exists on FreeBSD 12, >> so I have a probability of corruption between installation and compilation >> of the patched kernel... >> >> Don't know what more to do... >> > > What happens if you disable TRIM? > > Warner > >> >> Mario >> >> Em qua., 26 de fev. de 2020 às 20:48, Mark Linimon >> escreveu: >> >> > On Tue, Feb 25, 2020 at 08:18:51PM -0300, Mario Olofo wrote: >> > > the ZFS already shows corrupted data... >> > >> > Although this may have already been stated in the thread and I missed >> it, >> > I have not had similar problems with the NVME chips I have used (first >> an >> > HP, and now a Samsung). I am really starting to wonder if this is >> > hardware- >> > specific. >> > >> > mcl >> > >> ___ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
