Gary E. Miller via devel :
> How about "long long int"?
Sabjeev's last mail shows thet the parser will alteady handle a float
literal of the right size using the existing double type. Otherwise this
refclock shm unit 0 refid GPS time1 619315200.450 flag4 1
would fail. He says it doesn't.
That
Sanjeev Gupta :
> Eric,a data point. This works:
>
> refclock shm unit 0 refid GPS time1 619315200.450 flag4 1
>
> (the large number is 1024 weeks, the 0.450 is a delay)
That's good. Probably means there's a simple error in my asumtions about
how parsing works.
--
http://www.ca
Sanjeev Gupta :
> Eric,
>
> double is 8 bytes
> long double is 12 bytes
>
> Long double should be enough, I think
Agreed.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/
On 8/16/19 5:21 PM, Sanjeev Gupta via devel wrote:
> My new push (on Gitlab) uses (unsigned long long) , and tests OK on
> 32-bit and 64-bit systems.
It seems like you should be using a size-specific type here rather than
trying to find a type of the appropriate size manually and using that.
Use
Eric,a data point. This works:
refclock shm unit 0 refid GPS time1 619315200.450 flag4 1
(the large number is 1024 weeks, the 0.450 is a delay)
--
Sanjeev Gupta
+65 98551208 http://www.linkedin.com/in/ghane
On Sat, Aug 17, 2019 at 5:04 AM Eric S. Raymond wrote:
> Sanjeev Gupta :
> > Eri
Yo Sanjeev!
On Sat, 17 Aug 2019 06:21:18 +0800
Sanjeev Gupta wrote:
> > >>> a = 8192 * 7 * 24 * 60 * 60
> > >>> "%x" % a
> > '12750'
> >
> > Looks like 5 bytes to me. Is my math wrong?
> >
>
> No, but (long long) int is signed, so you only get to use 4 bytes. :-(
You just said long lo
On Sat, Aug 17, 2019 at 6:14 AM Gary E. Miller via devel
wrote:
>
> On Sat, 17 Aug 2019 06:07:14 +0800
> Sanjeev Gupta wrote:
>
> > The widest integer I have is "long long int", which is 8 bytes. I
> > need a bit more for "nuber of secs in 8192 weeks".
>
> Here is my math:
>
> seconds in 8192 w
Yo Sanjeev!
On Sat, 17 Aug 2019 06:07:14 +0800
Sanjeev Gupta wrote:
> Gary,
>
> The widest integer I have is "long long int", which is 8 bytes. I
> need a bit more for "nuber of secs in 8192 weeks".
Here is my math:
seconds in 8192 weeks = 8192 weeks * 7 days in week * 24 hours in a day *
Gary,
The widest integer I have is "long long int", which is 8 bytes. I need a
bit more for "nuber of secs in 8192 weeks".
I reproduce my attempt at C below, have I goofed up?
root@ntpmon:~/ntpsec# cat /tmp/aa.c
#include
int main()
{
int integerType;
long int longi
Yo Fred!
On Fri, 16 Aug 2019 15:00:40 -0700 (PDT)
Fred Wright via devel wrote:
> > Huh. If "long double" isn't 16 bytes, we're foing to have a
> > problem.
>
> There's no guarantee that long double differs from double. Anything
> that depends on it to do so is nonportable.
>
> That can't be
On Fri, 16 Aug 2019, Eric S. Raymond via devel wrote:
Sanjeev Gupta :
sizeof(double) seems to be 8 bytes. The 8192 * No of Secs per week
overflows this.
Huh. If "long double" isn't 16 bytes, we're foing to have a problem.
There's no guarantee that long double differs from double. Anythi
Yo Sanjeev!
On Sat, 17 Aug 2019 05:27:17 +0800
Sanjeev Gupta wrote:
> Gary,
>
> On my 32 bit x86, gcc 8
>
> Size of int: 4 bytesSize of long int: 4 bytesSize of long long int: 8
> bytesSize of float: 4 bytesSize of double: 8 bytesSize of long double:
> 12 bytesSize of char: 1 byte
>
> I have
Gary,
On my 32 bit x86, gcc 8
Size of int: 4 bytesSize of long int: 4 bytesSize of long long int: 8
bytesSize of float: 4 bytesSize of double: 8 bytesSize of long double:
12 bytesSize of char: 1 byte
I have cast explicitly to (long double), please review:
https://gitlab.com/NTPsec/ntpsec/merge_
Eric,
double is 8 bytes
long double is 12 bytes
Long double should be enough, I think
--
Sanjeev Gupta
+65 98551208 http://www.linkedin.com/in/ghane
On Sat, Aug 17, 2019 at 5:01 AM Eric S. Raymond wrote:
> Sanjeev Gupta :
> > Eric,
> >
> > sizeof(double) seems to be 8 bytes. The 8192 *
Yo Eric!
On Fri, 16 Aug 2019 17:01:02 -0400
"Eric S. Raymond via devel" wrote:
> Sanjeev Gupta :
> > Eric,
> >
> > sizeof(double) seems to be 8 bytes. The 8192 * No of Secs per week
> > overflows this.
>
> Huh. If "long double" isn't 16 bytes, we're foing to have a problem.
How about "long
Sanjeev Gupta :
> Eric,
>
> My (minimal) config:
>
> root@ntpmon:~/ntpsec/docs# grep -v "^#" /etc/ntp.conf | grep -v "^$"
> logfile /var/www/html/ntp/ntpd.log
> logconfig =syncall +clockall +peerall +sysall
> statsdir /var/www/html/ntp/
> filegen loopstats type day link
> filegen peerstats type
Sanjeev Gupta :
> Eric,
>
> sizeof(double) seems to be 8 bytes. The 8192 * No of Secs per week
> overflows this.
Huh. If "long double" isn't 16 bytes, we're foing to have a problem.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Yo Achim!
On Fri, 16 Aug 2019 22:43:19 +0200
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> > Yo Achim!
> >
> > On Fri, 16 Aug 2019 21:35:56 +0200
> > Achim Gratz via devel wrote:
> >
> >> Gary E. Miller via devel writes:
> >> >> The GT8736 is the same, just with the next
Eric,
My (minimal) config:
root@ntpmon:~/ntpsec/docs# grep -v "^#" /etc/ntp.conf | grep -v "^$"
logfile /var/www/html/ntp/ntpd.log
logconfig =syncall +clockall +peerall +sysall
statsdir /var/www/html/ntp/
filegen loopstats type day link
filegen peerstats type day link
filegen protostats type da
Gary E. Miller via devel writes:
> Yo Achim!
>
> On Fri, 16 Aug 2019 21:35:56 +0200
> Achim Gratz via devel wrote:
>
>> Gary E. Miller via devel writes:
>> >> The GT8736 is the same, just with the next-generation chipset and
>> >> fully active
>> >
>> > Got a source for those? I can't find one
Eric,
sizeof(double) seems to be 8 bytes. The 8192 * No of Secs per week
overflows this.
More info below:
root@ntpmon:/tmp# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/8/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --wit
Sanjeev, would you please look in your logs and see if the config
parser throws an error related to that line?
--
http://www.catb.org/~esr/";>Eric S. Raymond
You know why there's a Second Amendment? In case the government fails to
follow the first one.
-- Rush Limbaugh,
Yo Achim!
On Fri, 16 Aug 2019 21:35:56 +0200
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> >> The GT8736 is the same, just with the next-generation chipset and
> >> fully active
> >
> > Got a source for those? I can't find one for sale.
>
> I posted the link yesterday.
Gary E. Miller via devel writes:
>> The GT8736 is the same, just with the next-generation chipset and
>> fully active
>
> Got a source for those? I can't find one for sale.
I posted the link yesterday.
> Also, the specs do not look better than fair, and their protocol is
> undocumented.
Another
Sanjeev Gupta :
> I am using the SHM driver , which talks to gpsd. The presence of the "g"
> suffix causes the line to be ignored.
Working on it.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
devel mailing list
devel@ntpsec.org
Achim Gratz via devel :
> Eric S. Raymond via devel writes:
> > I read the Furuno specsheet and that indeed looks like a nice piece
> > of equipment. But Furuno lists it as discontinued, though. Can't find it
> > for sale on eBay or elsewhere on the web; there are hints it might have
> > EOLed in
Yo Achim!
On Fri, 16 Aug 2019 20:56:11 +0200
Achim Gratz via devel wrote:
> Eric S. Raymond via devel writes:
> > I read the Furuno specsheet and that indeed looks like a nice piece
> > of equipment. But Furuno lists it as discontinued, though. Can't
> > find it for sale on eBay or elsewhere on
Sanjeev Gupta :
> Eric,
>
> On a 32-bit debian:
>
> [ 73/101] Compiling ntpd/ntp_io.c
> ../../ntpd/ntp_scanner.c: In function ‘yylex’:
> ../../ntpd/ntp_scanner.c:40:30: warning: integer overflow in expression of
> type ‘long int’ results in ‘659554304’ [-Woverflow]
> #define GPS_ERA_13BIT (8192L
Yo Achim!
On Fri, 16 Aug 2019 20:41:35 +0200
Achim Gratz via devel wrote:
> Gary E. Miller via devel writes:
> > Note that is does not appear to support TSIP binary, only NMEA?
>
> To quote the relevant part of the product description:
>
> "Supports M12 binary protocol as well as identical f
Eric S. Raymond via devel writes:
> I read the Furuno specsheet and that indeed looks like a nice piece
> of equipment. But Furuno lists it as discontinued, though. Can't find it
> for sale on eBay or elsewhere on the web; there are hints it might have
> EOLed in 2014.
The GT8736 is the same, ju
Gary E. Miller via devel writes:
> Note that is does not appear to support TSIP binary, only NMEA?
To quote the relevant part of the product description:
"Supports M12 binary protocol as well as identical footprint to the Motorola
M12M device."
> So physically an Oncore replacement, but not cod
Eric,
I am using the SHM driver , which talks to gpsd. The presence of the "g"
suffix causes the line to be ignored.
root@ntpmon:~/ntpsec# grep refclock /etc/ntp.conf
refclock shm unit 0 refid GPS time1 0.650g flag4 1
root@ntpmon:~/ntpsec# kill -9 `pidof ntpd` ; ntpd -D 100
root@ntpmon:~/ntpsec
Eric,
On a 32-bit debian:
[ 73/101] Compiling ntpd/ntp_io.c
../../ntpd/ntp_scanner.c: In function ‘yylex’:
../../ntpd/ntp_scanner.c:40:30: warning: integer overflow in expression of
type ‘long int’ results in ‘659554304’ [-Woverflow]
#define GPS_ERA_13BIT (8192L * SECONDS_IN_WEEK)
I've just pushed a change that interprets a 'g' suffix on a clock time1
fudge option as an instruction to add the number of seconds in a
1024-week GPS era. There can be more than one g. Using this, you can
compensate for era rollover in old GPS devices.
Credit to James Browning for the idea. It's
34 matches
Mail list logo
