00:00:00 --- log: started forth/11.03.19 00:20:02 --- quit: gogonkt (Read error: Operation timed out) 00:23:41 --- join: gogonkt (~gogonkt@2001:c08:3700:ffff::19:6487) joined #forth 00:43:02 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth 00:43:04 harlan: ntp? 00:43:57 segher: ? 00:45:56 i am asking what that NTP project is 00:49:32 The one maintaining NTP software. 00:49:45 heh 00:50:17 NTP is kind of fundamental service, it is rather hard to live without it. 00:51:05 i doubt this is the same thing 00:52:33 Even when I know that "NTP" means "nauchno-tekhnicheskij progress," 00:52:56 I understand what NTP means in network context. 00:58:13 well sure. but there is no such context here 00:59:52 You're on the Internet. 01:05:01 ntp is about using network time protocol to set computer's rtc and kernel time 01:06:01 NTP is a TLA, it could mean anything, duh 01:11:42 --- join: qFox (~C00K13S@5356B263.cm-6-7c.dynamic.ziggo.nl) joined #forth 01:22:58 --- join: tathi (~josh@dsl-216-227-95-5.fairpoint.net) joined #forth 01:32:49 segher: Network Time Protocol. Keeping clocks right. 03:36:07 --- join: MayDaniel (~MayDaniel@91.84.41.221) joined #forth 03:36:08 --- quit: MayDaniel (Changing host) 03:36:08 --- join: MayDaniel (~MayDaniel@unaffiliated/maydaniel) joined #forth 03:36:45 --- quit: MayDaniel (Read error: Connection reset by peer) 04:14:09 --- quit: qFox (Quit: Time for cookies!) 05:43:04 --- join: MayDaniel (~MayDaniel@unaffiliated/maydaniel) joined #forth 06:30:43 harlan: hrm, what do you want a threaded code engine for, in that? 06:40:58 --- quit: ygrek (Remote host closed the connection) 06:58:14 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth 08:21:46 --- quit: gogonkt (Remote host closed the connection) 08:21:57 --- join: gogonkt (~gogonkt@2001:c08:3700:ffff::19:e09f) joined #forth 09:20:27 segher: https://support.ntp.org/bin/view/Dev/GSoCProjectIdeas#Refclock_Definition_Language 10:54:26 hrm 10:55:30 --- quit: nighty^ (Ping timeout: 252 seconds) 11:02:32 segher: We're looking to create a "reference clock definition language" - a way to have the NTP daemon talk to things that supply time. 11:03:36 https://support.ntp.org/bin/view/Dev/GSoCProjectIdeas#Refclock_Definition_Language 11:08:01 is anyone running msdos on linux? i need a .exe zipped file opened and tarred up. 11:10:55 --- join: nighty^ (~nighty@tin51-1-82-226-147-104.fbx.proxad.net) joined #forth 11:23:24 --- quit: gogonkt (Ping timeout: 252 seconds) 11:36:32 --- join: impomatic (~chatzilla@87.115.118.174) joined #forth 11:38:31 --- quit: tripFantastic (Quit: BitchX Lite I said!) 12:25:40 --- join: qFox (~C00K13S@5356B263.cm-6-7c.dynamic.ziggo.nl) joined #forth 12:32:53 --- quit: MayDaniel (Read error: Connection reset by peer) 12:37:00 harlan: in what way does it have to be safe? 12:37:09 i have no student for you btw 12:38:45 is it fine to crash the engine (controlled crash), for example? 12:43:18 abort with an error is OK, crashing the process is not. 12:44:03 We don't want folks to be able to access memory other than what they should be "expected" to see, or transfer control somewhere outside of the "environment" they are running in . 12:44:21 right 12:44:41 so you want to have separate code and data space, and both limited 12:45:09 probably nest to do an engine per refclock then 12:45:13 best 12:47:32 that would be fine, and I'm also OK having a single main engine that partitions each target. This should not be a big deal either way, as most folks will not have any of these, and the ones that have refclocks will almost always have 1. It is a small number of people who have multiple refclocks, and if they do I suspect the overhead of a dedicated engine will not be that high. 12:48:19 We'd "enforce" that the subroutines that the engine called would be non-blocking as far as IO and stuff went. 12:48:39 we do not want to require threads, for example. 12:51:04 do you want to make sure the engine itself is non-blocking as well? 12:51:18 yes 12:51:30 harlan: out of forth world, a ficl may do, integrates nicely with any C application and librares 12:51:40 you usually cannot, but you can have a dead-man timer or something 12:52:12 what would cause something to block? 12:52:21 a simple endless loop will do 12:52:56 the "main loop" for ntpd cannot block - it messes up timekeeping. 12:53:19 right, so you want to limit how much work is done per call of the engine 12:53:40 so we'd call an "init" routine, and then we'd make a call to the engine to process something when we knew there was data to be processed. 12:54:08 the "worst" that would happen is there is a short read. 12:54:34 and we generally do not worry about writes blocking, but we can easily handle that because we'd be controlling the subroutine that is called to handle the writes. 12:54:41 but there is no way you can be sure the program in the engine takes any finite amount of time, before running it, for any non-trivial program and language 12:54:48 So we could buffer that and let our event processing model handle it. 12:54:51 it's the halting problem, basically 12:54:56 right. 12:55:07 But we're doing small-enough bites that this should not be an issue. 12:55:23 sure, and as i said, you can detect run-away programs easily 12:55:36 harlan: data are read mostly via some serial interface? 12:55:52 yes. 12:56:35 There are some clocks that give us data via a memory address. But it's mostly device I/O, and from that mostly serial. 12:56:40 serial as in uart? is the latency and jitter small enough? 12:57:01 so there are fifos, interrupts and similar stuff? 12:57:11 serial is usually OK - USB sucks. 12:57:18 ha 12:57:39 rs232 is bloody unrealiable as well 12:57:41 And some OSes do better than other with latency and jitter over serial lines than others. 12:57:45 :) 12:58:19 well, you'll have on the order of a millisecond latency 12:58:36 for very short messages :-P 12:59:00 sounds about right, for the general case. 12:59:14 is that good enough for a refclock? hrm 12:59:43 a PPS signal can come in over the DTR line (for example). 12:59:59 ah, so not really serial :-) 13:00:06 just a single signal line 13:00:38 As long as we know when the stroke of a second is, we can start pushing out the time we "check", so if we get 1ms of jitter when we push the poll interval to 1 day, things start to get more accurate. 13:00:52 and some drivers will give us hardware timestamping. 13:01:08 yah 13:01:27 --- quit: impomatic (Quit: ChatZilla 0.9.86.1 [Firefox 3.5.17/20110121150729]) 13:01:57 so why do you want interpreted programs -- so you can load drivers at runtime easily? 13:02:24 Right now the drivers are .o files. It requires compiling C code and relinking. 13:02:53 right 13:03:03 and if one goes bad, it takes everything down 13:03:03 I do not want to rely on dlopen() in general, and for a process that runs as root I do not want to open the door to the case where folks can easily drop in C code. 13:03:14 that's usually not a problem :) 13:03:22 you'll nicely avoid most portability stuff as well 13:03:39 I think that if we have something like termcap or modemcap, we could use a simple bytecode, and the ntp process 13:03:42 yes 13:03:56 harlan: my unsolicited advice from far far away you should keep static modules as long as possible (picking up the right ones at compile time, if needed) 13:04:03 yeah, i'd recommend some bytecode 13:04:09 can simply read and parse these "drivers", and we have a portable, safe, and easy way to handle the time interface. 13:04:10 stack-based though 13:04:56 the question is how low-level access to ports etc. is portable 13:05:01 The static modules are fine, and the thing is I'm trying to make it easy for folks who don't care, and also easy for folks who want to make changes. 13:05:11 you simply call some support routine that does that 13:05:18 We'll handle the port access via a subroutine API. 13:05:25 We do that already. 13:05:37 there is no other way really :-) 13:06:18 We originally supported (and may still support) LDISC stuff and STREAMS from solaris. 13:06:44 --- join: davehart (hart@ntp/developer/davehart) joined #forth 13:07:08 fun 13:07:20 davehart is on the project with me. 13:07:26 has the codebase ever gotten a complete rewrite? 13:07:28 ldisc is almost gone from freebsd, sadly 13:08:16 We have 2 sets of refclocks, the "original" design, and the "parse" refclocks. The latter are a step toward more generic timestamp processing, but still all written in C. 13:08:34 We have pre-assigned refclock numbers, and there is a strong push to not add more. 13:08:56 where is your source repository? 13:09:01 the name "parse" implies something very different that what we have 13:09:07 If we can come up with a "Refclock Definition Language" that uses threaded/bytecode, I can replace all of the mess with that, and solve several problems at once. 13:09:16 is "parse" something with common pps code? 13:10:11 http://archive.ntp.org/ntp4/ntp-dev/ and browse at http://ntp.bkbits.net:8080/ntp-dev/ 13:10:42 Our code is in a BitKeeper repository. View access is at ntp.bkbits.net. We publish snapshots every night there is a change, at http://support.ntp.org/downloads 13:11:05 parse is a frankendriver that has exploded out with subdrivers while there has been a practical moratorium on new ntpd refclock major driver numbers 13:11:07 I think so - the PPS stuff is in the "parse" refclocks and several others. 13:11:21 ah bitkeeper 13:11:30 ah tarballs 13:11:56 good 13:13:41 there is a thin layer of common PPSAPI interface code in ntp_refclock.c shared by a number of drivers including NMEA, PPS/atom, WWVB, and some of the parse subdrivers. parse drivers, like many, used to have independent per-driver PPSAPI interfacing which was problematic, particularly where PPSAPI is glued on after-the-fact using inline functions in a user-supplied timepps.h header. 13:14:47 it was also duplicative and reflected a bunch of snapshots of evolving PPS interfacing ideas (not all remnants of which have been cleaned up even now, particularly in less popular drivers) 13:15:36 yes, another reason to go to an RDL is that it means we pretty much have to use a single codebase to handle all of the refclocks. It will solve a bitrot problem. 13:15:58 I can't find anything parsing anything except configuration files in refclock_parse or its libs, though. 13:16:00 so will there be any way to test new drivers for all supported hardware? 13:16:22 harlan: that seems like a huge leap of logic to me. 13:16:44 davehart: one of these days I will traverse a chasm in 2 leaps. 13:17:04 while I admit ripping and redoing the refclock interface entirely could be productive, I don't understand why support for such a beast would somehow require existing drivers be broken 13:17:04 :-) 13:17:25 segher: I don't think this situation will be any worse than what we have now. Also, we are starting to implement unit tests, and also grow a test lab. 13:17:41 Otherwise, we rely on our "crew" to test the refclocks they have that we do not. 13:18:01 well, if no one can test some hardware, then you can conclude no one has that hardware, so you can drop the driver, right :-) 13:18:56 ntp-dev-4.2.7p140.tar.gz appears to be truncated: 5498453/5501327 bytes 13:18:58 in theory yes. In practice, we would not want to, and a "benefit" of an RDL is that there is pretty much no cost to keeping older RDL-drivers around. 13:19:16 yes, but you first have to get there 13:19:25 yes. 13:19:29 * harlan checks the tarball 13:20:00 so do you keep the old C driver if no one can test the new bytecode driver, or hope for the best and convert? 13:20:32 oh, ftp at archive.ntp.org has only snapshots until july 2010 13:21:07 i imagine you'll have some conversion period (of some years perhaps), but you really want to eradicate all the old stuff by some point 13:21:17 I don't think the cost of rdl will be lower than that of C 13:21:37 cost in what way 13:21:59 I just downloaded http://archive.ntp.org/ntp4/ntp-dev/ntp-dev-4.2.7p140.tar.gz and it was not truncated... 13:22:01 it may provide some abstractions or sandboxing but may introduce bugs and another layer always adds some complexity 13:22:17 that will be very limited 13:22:35 the "extra complexity" 13:22:37 harlan: might be my proxy 13:23:08 I'll have a look at the code first instead of making theoretical assumptions :) 13:23:35 and while we would be trading one set of hassles for another, I like that we'd no longer have "a bunch of stand-alone drivers" and "the parse driver", and folks could easily tweak things for their use, and be reasonably certain it would not cause a security problem. 13:23:47 i've had a student write bytecode device drivers before 13:23:57 (for linux) 13:24:05 based on FCode 13:24:53 if they were good and still eligible... 13:25:30 Another thing is that right now we have "lean and mean" drivers (ie, they break if anything strange happens" and we have "very-well-engineered" drivers. 13:25:39 that was years ago, heh 13:25:41 We can easily make that more consistent if we use an RDL. 13:26:19 We got lucky a few years ago - a fairly senior guy decided to go for a Masters Degree, and was able to do his project using GSoC. 13:26:41 We also had a PhD do things (he might have been post-doc) 13:30:58 harlan: strange, the file was truncated when using IPv6, with IPv4 it was ok, which is worrying 13:31:58 if you can duplicate this, please let us know - we've been supporting IPv6 for a long time. 13:34:17 looking at reflock_oncore.c 13:34:25 harlan: yes, every time I do it over ipv6 13:34:32 let me try from another v6 box 13:34:46 davehart is running IPv6... 13:34:55 refclock_oncore.c <-- could by much shorter and nicer in Forth 13:34:56 I have yet to set it up on my home machine. 13:35:18 I am using SixXS, they are pain to register, but after that it's okay 13:35:25 that is a "well-engineered" driver. 13:36:45 buf[l + i * (mp->len+3) + 1] = mp->len & 0xff; 13:37:42 such code looks usually nicer 13:39:14 harlan: must be my local ipv6 connection problem, it downloads fine on the server with native ipv6 13:40:36 'k 14:02:10 I don't see Dr. Mills letting you convert the drivers he uses away from C 14:06:36 --- quit: ygrek (Ping timeout: 246 seconds) 14:12:12 had a look at refclock_tt560.c and I have a question 14:13:55 er no 14:14:36 the question goes for refclock_gpsvme.c: how things like ioctl(fd[unit], PSC_REGS, ®p[unit]) you'd like to have implemented? 14:21:52 --- join: SunTzu (1000@c-68-56-234-19.hsd1.fl.comcast.net) joined #forth 14:26:32 hm lots of refclock drivers depend on the kernel support anyway 14:35:48 I've wondered the same thing, saper. Harlan's talk of having only RDL-based drivers implies he does want to include those using hardware or OS-specific access (compared to the more prevalent serial timecode with PPS on serial or parallel port) 14:37:19 --- quit: qFox (Read error: Connection reset by peer) 14:45:12 okay 14:45:29 if FreeBSD would be only OS in the world, I'd put refclock drivers in the kernel. 14:45:54 actually currect C code could be probably easily adapted 14:46:07 actually I need to check how current base system ntpd handles that 14:46:29 since there are obviously no special /dev/xxx drivers 15:05:35 I never did proper NTP (with refclock) but can I use refclock_gpsvme.c for example on FreeBSD? 15:05:53 it references /dev/refclock%d I'm unlikely to have, or am I mistaken? 15:23:34 just do it 16:03:24 Frank Kardel did put refclock drivers in the kernel on some Sun systems 16:04:03 I'm not sure of the details but it's in the tarball, and if you build on solaris 10 sparc I know it actually builds the kernel driver stuff 16:05:28 it's all tucked away in the libparse directory, that Makefile.am has the special rules to build the kernel versions of some of the clk_*.c and supporting code 16:07:18 typically the operator is expected to ln -s to link the name the refclock driver will open, such as /dev/pps0, to whatever underlying device provides it, such as /dev/ttyS0 16:07:50 It's one of the many ways you can fail to get a refclock going. a bit finicky. 16:09:25 I owuld certainly include the drivers that eded low-level hardware support. I'd simply write a subroutine that the bytecode would call that would "do the job". 16:09:54 so for: ioctl(fd[unit], PSC_REGS, ®p[unit]) 16:10:52 we'd have a subroutine that would know the unit number (so we could map fd[unit], it would be designed to call the ioctl with PCS_REGS, and it would do the data translation to move the data to/from what is now the regp[unit] area. 16:11:51 that's a poor example 16:12:12 most drivers do not use unit arrays, though it was once common (as was a 4-unit limit) 16:12:51 mostly drivers now find their unit-specific data through peer->procptr->unitptr or so 16:13:49 in those newer drivers the unit argument to the driver entrypoints is ignored 16:15:46 when they do reference the unit number it's through refnumtoa(&peer->srcadr) (it's the low octet of the v4 pseudo addr for refclocks) 16:30:25 It may be a poor example, but I am looking for a way to handle *all* of our refclocks, even if we have to redesign some of the drivers. If what we come up with doesn't work and nobody notices, then we can deprecate the driver. 18:17:45 --- quit: tathi (Quit: leaving) 18:34:45 --- join: gogonkt (~gogonkt@2001:c08:3700:ffff::1a:38ad) joined #forth 19:27:22 --- join: Deformative (~Joseph@c-68-84-165-215.hsd1.mi.comcast.net) joined #forth 21:50:03 --- join: nixness (~dsc@dyn-86-36-42-164.wv.qatar.cmu.edu) joined #forth 22:00:34 --- quit: nixness (Quit: Leaving) 22:09:21 can i get a yay? my thought to building up a forth kernel incrementally is working!!! 22:33:07 yay! 22:33:26 tyvm 22:33:39 now i have write.2 output to stdout 22:43:55 :D 22:58:22 --- join: ygrek (debian-tor@gateway/tor-sasl/ygrek) joined #forth 23:04:13 so why do Forthers cringe on ITC? 23:32:25 --- join: DocPlatypus (~skquinn@dsl253-084-031.hou1.dsl.speakeasy.net) joined #forth 23:32:38 hi doc 23:32:50 hey 23:59:59 --- log: ended forth/11.03.19