HECnet

hecnet@lists.dfupdate.se

15586 discussions

Start a nNew thread

Unsubscribe

by Rien Timmer

Groeten, Rien Timmer

3 years, 10 months

DN60 etc. --> Anf10 family based?

by R. Voorhorst

Thomas, If I recall correctly it is Anf10 related and has it's own runtime and Chk11 for initial testing of hardware. Thus it had to fit in 28 kW; no relations to Rsx11 or even RT11. The code pieces then should be *.P11 etc. Reindert -----Original Message----- From: Thomas DeBellis [mailto:tommytimesharing@gmail.com] Sent: Monday, 31 January, 2022 21:22 To: hecnet(a)lists.dfupdate.se Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective Then we are probably talking apples and pineapples. The product that I'm talking about is exclusively for the 36 bit line, requiring a DTE to get the data to the PDP-10. I think it also needed a KMC to do some offloading, so the 11/34 could keep up, but I wouldn't swear to it. There's code for a KMC, anyway. The software appears to be a complete embedded design: there are no users, no file system, minimum memory management and no task preemption. Thus, I don't believe it has any code basis in either RSX or RSTS. I wouldn't be surprised if part of it got lifted from RT-11, but I don't have an informed opinion on that. The DN60/DN65 spoke 2780, 3780 and HASP. The first two are remote job entry (RJE) 'workstations' that had card readers and line printers (no terminals). HASP is a variant that IBM did not develop, yet adopted. I believe it was wizzy because it allowed multiple concurrent streams. The job of IBMSPL was to fool the remote IBM host that a card deck was being submitted by a timesharing user and to take the resulting print output and to get it to wherever the right place was (printer, file, etc.) I don't recall a 3271, I guess you mean those green screen terminals? What a beast... I do recall using 3270, 3276 and the like when I was hacking the bisync drivers on VM to talk to IBMSPL. There was a product that you could run on Tops-20 to show up as a 3270 on an IBM box, provided the target spoke TCP/IP. I can't remember the name, but it was based on TELNET negotiating some additional options. It's a lot of work; a 3270 is not like anything you ever heard of in ÅSCII land. A number of us swore that IBMSPL was the only reasonable way to use an IBM mainframe as the 3270 was a half-duplex terminal that was all to ready to lock the keyboard if you even thought of typing ahead. The more modern emulators don't lock like that, but you are still effectively in a late 1960's half duplex paradigm. Still. Today. Really. On 1/31/22 3:00 PM, Paul Koning wrote: > What I mentioned is one or several PDP-11 products, available for RSTS and I believe RSX. There definitely is an "RJ2780 emulator" -- the official name may not be quite that. And I think there was also a 3271 emulator, though I'm not sure if that existed on RSTS. > > I have no idea what these things do, since 2780 is something I've never used. Some sort of remote job entry station? Anyway, it is the only RSTS software that uses a KG11. DECnet doesn't because on RSTS DECnet only supported devices with hardware CRC: DMC and friends and later Ethernet. I did an unsupported software DDCMP, but that does CRC in software (8 bits at a time, the classic table driven fast software implementation). That probably outruns a KG11 and in any case I never had access to that hardware. > > paul > >> On Jan 31, 2022, at 2:52 PM, Thomas DeBellis <tommytimesharing(a)gmail.com> wrote: >> >> I wanted to make sure I wasn't getting lost; are you referring to the PDP-11 software that forms part of the Galaxy IBM workstation product? It's called DN60/DN65 and also does 3780 and HASP. Is this what you're referring to? >> >> On 1/31/22 2:48 PM, Peter Allan wrote: >>> Paul Koning wrote ... >>> >>>> Correct, I was not aware it's possible to use it. The only software I have seen that uses the KG11 is 2780 emulation. >>> I am very interested in getting 2780 emulation for a PDP-11. >>> >>> Paul, or anyone else, do you know where I can get it? >>> >>> Cheers >>> >>> Peter Allan >>> _______________________________________________ >>> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send >>> an email to hecnet-leave(a)lists.dfupdate.se >> _______________________________________________ >> HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send >> an email to hecnet-leave(a)lists.dfupdate.se > _______________________________________________ > HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an > email to hecnet-leave(a)lists.dfupdate.se _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

3 years, 10 months

KG11 emulation probably defective -->diagnostic ZKGAB0 for KG11 runs without complaints.

by R. Voorhorst

L.S. The diagnostics in XXDP for KG11 completes without problems, so far, so good. It limits the scope to interface problems between Decnet11MP and Simh KG11. Reindert -----Original Message----- From: R. Voorhorst [mailto:R.Voorhorst@swabhawat.com] Sent: Sunday, 30 January, 2022 16:18 To: 'The Hobbyist DECnet mailing list' <hecnet(a)lists.dfupdate.se> Subject: [HECnet] Re: native Dup sync line revisited --> KG11 emulation probably defective --> initial exploration L.S. Reviewing the code from J. Dundas reveals it passed a diagnostic ZKGAB0 which is a xxdp component. There are listings of maindecs, no sources and the microfiche listing quality is quite low, so restoration of source code is laborious at best. It also happens to be a component of Anf10 for Tops10 and any image has a quick check for the KG11 if configured to be present. I think for now the chance that the KG11 itself is somehow corrupt is low regarding the well specified design path followed in creation, so probably a mismatch between Rsx11 software and the current KG11 implementation is more probable cause. It also appears the KG11 was used in the Rsts corner for Dup, Dp and Du and the Ibm 2780 interfaces. The docs in simh KG11 does not reveal whether it was tested in a simulated actual software system. Lacking the diagnostics sources except Chk11.P11 which is very limited in scope, XXDP might be the ultimate quickest way to test it. Reindert -----Original Message----- From: R. Voorhorst [mailto:R.Voorhorst@swabhawat.com] Sent: Sunday, 30 January, 2022 09:53 To: 'The Hobbyist DECnet mailing list' <hecnet(a)lists.dfupdate.se> Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test on pdp11 --> KG11 emulation probably defective Apart from morons with an incurable inclination to the complex difficult thereby shooting in the own feet like me .... ? I do not know, but I suppose on Rsx11 the serial async Decnet lines might use KG11 assisted crc16 generation/checking as well and the problem might be in Rsx11M software itself, less likely, or more likely in KG11 simulation. Johnny might know this. As I have done the KG8 I think I am more predisposed to look at the KG11 excepting the writer of the KG11 simulation, so I will check for the existence of a diagnostic, will see what goes wrong and propose a fix. KG11 is not a complex device. Best regards, Reindert -----Original Message----- From: Mark Pizzolato - Info Comm [mailto:Mark@infocomm.com] Sent: Sunday, 30 January, 2022 01:26 To: R. Voorhorst <R.Voorhorst(a)swabhawat.com>; hecnet(a)lists.dfupdate.se Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective On Saturday, January 29, 2022 at 4:04 PM, R. Voorhorst wrote: > L.S. > > With a bit time on hand and the standstill after Paul's initial test > from dup to pydecnet which appeared to be successful, I now undertook > a test as Mark liked to have it preferably. > So I did a fresh netgen on a simple configuration from simple basic > install Rsx11MP system for only a Decnet end-node with one single Dup > line communicating to a known working Pdp11 Rsx11MP Dmc circuit. > > I saw no difference from what I reported initially and later with > logging, as was to be expected; my complex setup behaves exactly the > same in this respect as it does for years in a complex network setup > for Rsx and Rsts, and > RT11 without network. > > This is on a Windows-2008R2 server and I suspect Paul did his test on > unix/linux , however although it differs, that should be moot as far > as Simh is concerned. > > There could be another difference though. Paul would probably have > taken the default route and used Ddcmp withouth KG11 support: Dup > without Kdp is the only sync line to use it, though async Decnet > DL/DZ/VH might use it as well. > As I prefer the most complex configs possible (any two of a kind where > possible as Dec used to have them), I do also employ the KG11, so for > Dup support it will be used when configured so in Decnet11MP. > On a sim it is not that effective, but in hardware in the past it did > make a difference for fast crc computing. > > So I retested with no KG11 support and indeed, now the Dup works as > expected. > What appears to be strange is, that small packets up to 8 bytes are > not corrupted but the larger ones do. Maybe in Decnet11MP, the small > packets are totally preconfigured in the software program with crc > inclusive and the > KG11 is then bypassed effectively, bu, that should have to be > verified. At least the combination KG11 and Decnet11MP KG11 support is defective. > > So Simh Dup works in software Ddcmp packet generation, but the Simh > KG11 seem to generate bad checksums and/or checks. > For the Pdp8A, I have a functioning KG8 simulation that works in > Rts-8, so there is a test reference to fall back on. > > So I admit and confirm that basic Dup in simh software wise between > Pdp11's and with various counterparts (DMC) indeed works, which would > make it serve as a base for other sync line implementations like DP8-E(A). So, you've proven to yourself that the KG11 is at least somewhat broken. Looking back at the change history for this device, I've made changes relating to how it glues into the PDP11 I/O space, but nothing at all about how the device actually functions. What else uses this device? Is there a diagnostic? - Mark _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

3 years, 10 months

Re: KG11 emulation probably defective -->diagnostic ZKGAB0 for KG11 runs without complaints. --> Crc on Rsx11 async lines

by R. Voorhorst

By the way, Johnny, was KG11 also used on serial async Decnet11MP lines or was that always software? Reindert -----Original Message----- From: Johnny Billquist [mailto:bqt@softjar.se] Sent: Monday, 31 January, 2022 08:15 To: hecnet(a)lists.dfupdate.se Subject: [HECnet] Re: KG11 emulation probably defective -->diagnostic ZKGAB0 for KG11 runs without complaints. I agree that it would be nice to confirm that this works in real hardware, but I also find it unlikely that it wouldn't. While DEC was not perfect, I would expect that they actually had tested this before releasing the software. Johnny On 2022-01-31 01:51, R. Voorhorst wrote: > @Dave: > > It would only be worth the time and energy to prove if current > Decnet11MP in combination with KG11 would work in a Dup to Dup or Dmc > connection, which in hardware take a serious effort. > In virtual reality it is far more easy to arrange such things. > Unless I cannot find a bug quickly enough, then it could be helpful to > request you to check on it. > > > Thanks though for the time being. > > Reindert > > -----Original Message----- > From: Dave McGuire [mailto:mcguire@neurotica.com] > Sent: Sunday, 30 January, 2022 18:25 > To: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se> > Subject: [HECnet] Re: KG11 emulation probably defective -->diagnostic > ZKGAB0 for KG11 runs without complaints. > > On 1/30/22 12:21 PM, Mark Pizzolato - Info Comm wrote: >> On Sunday, January 30, 2022 at 5:34 AM, Reindert wrote: >>> The diagnostics in XXDP for KG11 completes without problems, so far, >>> so > good. >>> It limits the scope to interface problems between Decnet11MP and >>> Simh > KG11. >> >> We really don't know how robust the diagnostic is and if it exercises >> the same details that are used by the DDCMP implementation. >> >> You could run the DDCMP case with KG11 debugging enabled and identify >> what > it is doing precisely and then go back and see if the diagnostic is > doing the same stuff... > > I have a KG11-A board; if it would be helpful, I can install it in > a > PDP-11 at LSSM perhaps this week. > > -Dave > > -- > Dave McGuire, AK4HZ > New Kensington, PA > _______________________________________________ > HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an > email to hecnet-leave(a)lists.dfupdate.se > > _______________________________________________ > HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an > email to hecnet-leave(a)lists.dfupdate.se -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

3 years, 10 months

Re: native Dup sync line revisited --> KG11 emulation probably defective --> initial exploration

by R. Voorhorst

L.S. Reviewing the code from J. Dundas reveals it passed a diagnostic ZKGAB0 which is a xxdp component. There are listings of maindecs, no sources and the microfiche listing quality is quite low, so restoration of source code is laborious at best. It also happens to be a component of Anf10 for Tops10 and any image has a quick check for the KG11 if configured to be present. I think for now the chance that the KG11 itself is somehow corrupt is low regarding the well specified design path followed in creation, so probably a mismatch between Rsx11 software and the current KG11 implementation is more probable cause. It also appears the KG11 was used in the Rsts corner for Dup, Dp and Du and the Ibm 2780 interfaces. The docs in simh KG11 does not reveal whether it was tested in a simulated actual software system. Lacking the diagnostics sources except Chk11.P11 which is very limited in scope, XXDP might be the ultimate quickest way to test it. Reindert -----Original Message----- From: R. Voorhorst [mailto:R.Voorhorst@swabhawat.com] Sent: Sunday, 30 January, 2022 09:53 To: 'The Hobbyist DECnet mailing list' <hecnet(a)lists.dfupdate.se> Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test on pdp11 --> KG11 emulation probably defective Apart from morons with an incurable inclination to the complex difficult thereby shooting in the own feet like me .... ? I do not know, but I suppose on Rsx11 the serial async Decnet lines might use KG11 assisted crc16 generation/checking as well and the problem might be in Rsx11M software itself, less likely, or more likely in KG11 simulation. Johnny might know this. As I have done the KG8 I think I am more predisposed to look at the KG11 excepting the writer of the KG11 simulation, so I will check for the existence of a diagnostic, will see what goes wrong and propose a fix. KG11 is not a complex device. Best regards, Reindert -----Original Message----- From: Mark Pizzolato - Info Comm [mailto:Mark@infocomm.com] Sent: Sunday, 30 January, 2022 01:26 To: R. Voorhorst <R.Voorhorst(a)swabhawat.com>; hecnet(a)lists.dfupdate.se Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective On Saturday, January 29, 2022 at 4:04 PM, R. Voorhorst wrote: > L.S. > > With a bit time on hand and the standstill after Paul's initial test > from dup to pydecnet which appeared to be successful, I now undertook > a test as Mark liked to have it preferably. > So I did a fresh netgen on a simple configuration from simple basic > install Rsx11MP system for only a Decnet end-node with one single Dup > line communicating to a known working Pdp11 Rsx11MP Dmc circuit. > > I saw no difference from what I reported initially and later with > logging, as was to be expected; my complex setup behaves exactly the > same in this respect as it does for years in a complex network setup > for Rsx and Rsts, and > RT11 without network. > > This is on a Windows-2008R2 server and I suspect Paul did his test on > unix/linux , however although it differs, that should be moot as far > as Simh is concerned. > > There could be another difference though. Paul would probably have > taken the default route and used Ddcmp withouth KG11 support: Dup > without Kdp is the only sync line to use it, though async Decnet > DL/DZ/VH might use it as well. > As I prefer the most complex configs possible (any two of a kind where > possible as Dec used to have them), I do also employ the KG11, so for > Dup support it will be used when configured so in Decnet11MP. > On a sim it is not that effective, but in hardware in the past it did > make a difference for fast crc computing. > > So I retested with no KG11 support and indeed, now the Dup works as > expected. > What appears to be strange is, that small packets up to 8 bytes are > not corrupted but the larger ones do. Maybe in Decnet11MP, the small > packets are totally preconfigured in the software program with crc > inclusive and the > KG11 is then bypassed effectively, bu, that should have to be > verified. At least the combination KG11 and Decnet11MP KG11 support is defective. > > So Simh Dup works in software Ddcmp packet generation, but the Simh > KG11 seem to generate bad checksums and/or checks. > For the Pdp8A, I have a functioning KG8 simulation that works in > Rts-8, so there is a test reference to fall back on. > > So I admit and confirm that basic Dup in simh software wise between > Pdp11's and with various counterparts (DMC) indeed works, which would > make it serve as a base for other sync line implementations like DP8-E(A). So, you've proven to yourself that the KG11 is at least somewhat broken. Looking back at the change history for this device, I've made changes relating to how it glues into the PDP11 I/O space, but nothing at all about how the device actually functions. What else uses this device? Is there a diagnostic? - Mark _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

3 years, 10 months

Re: native Dup sync line revisited --> revisited Dup test on pdp11 --> KG11 emulation probably defective

by R. Voorhorst

Apart from morons with an incurable inclination to the complex difficult thereby shooting in the own feet like me .... ? I do not know, but I suppose on Rsx11 the serial async Decnet lines might use KG11 assisted crc16 generation/checking as well and the problem might be in Rsx11M software itself, less likely, or more likely in KG11 simulation. Johnny might know this. As I have done the KG8 I think I am more predisposed to look at the KG11 excepting the writer of the KG11 simulation, so I will check for the existence of a diagnostic, will see what goes wrong and propose a fix. KG11 is not a complex device. Best regards, Reindert -----Original Message----- From: Mark Pizzolato - Info Comm [mailto:Mark@infocomm.com] Sent: Sunday, 30 January, 2022 01:26 To: R. Voorhorst <R.Voorhorst(a)swabhawat.com>; hecnet(a)lists.dfupdate.se Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective On Saturday, January 29, 2022 at 4:04 PM, R. Voorhorst wrote: > L.S. > > With a bit time on hand and the standstill after Paul's initial test > from dup to pydecnet which appeared to be successful, I now undertook > a test as Mark liked to have it preferably. > So I did a fresh netgen on a simple configuration from simple basic > install Rsx11MP system for only a Decnet end-node with one single Dup > line communicating to a known working Pdp11 Rsx11MP Dmc circuit. > > I saw no difference from what I reported initially and later with > logging, as was to be expected; my complex setup behaves exactly the > same in this respect as it does for years in a complex network setup > for Rsx and Rsts, and > RT11 without network. > > This is on a Windows-2008R2 server and I suspect Paul did his test on > unix/linux , however although it differs, that should be moot as far > as Simh is concerned. > > There could be another difference though. Paul would probably have > taken the default route and used Ddcmp withouth KG11 support: Dup > without Kdp is the only sync line to use it, though async Decnet > DL/DZ/VH might use it as well. > As I prefer the most complex configs possible (any two of a kind where > possible as Dec used to have them), I do also employ the KG11, so for > Dup support it will be used when configured so in Decnet11MP. > On a sim it is not that effective, but in hardware in the past it did > make a difference for fast crc computing. > > So I retested with no KG11 support and indeed, now the Dup works as > expected. > What appears to be strange is, that small packets up to 8 bytes are > not corrupted but the larger ones do. Maybe in Decnet11MP, the small > packets are totally preconfigured in the software program with crc > inclusive and the > KG11 is then bypassed effectively, bu, that should have to be > verified. At least the combination KG11 and Decnet11MP KG11 support is defective. > > So Simh Dup works in software Ddcmp packet generation, but the Simh > KG11 seem to generate bad checksums and/or checks. > For the Pdp8A, I have a functioning KG8 simulation that works in > Rts-8, so there is a test reference to fall back on. > > So I admit and confirm that basic Dup in simh software wise between > Pdp11's and with various counterparts (DMC) indeed works, which would > make it serve as a base for other sync line implementations like DP8-E(A). So, you've proven to yourself that the KG11 is at least somewhat broken. Looking back at the change history for this device, I've made changes relating to how it glues into the PDP11 I/O space, but nothing at all about how the device actually functions. What else uses this device? Is there a diagnostic? - Mark _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

3 years, 10 months

Re: HECnet Digest, Vol 2, Issue 9

by Wilm Boerhout

I am forwarding all enquiries for the hardware in Zoetermeer. Expect to hear from Tony M. Wilm -----Original Message----- From: hecnet-request(a)lists.dfupdate.se <hecnet-request(a)lists.dfupdate.se> Sent: Saturday, January 29, 2022 5:45 PM To: hecnet(a)lists.dfupdate.se Subject: HECnet Digest, Vol 2, Issue 9 Send HECnet mailing list submissions to hecnet(a)lists.dfupdate.se To subscribe or unsubscribe via email, send a message with subject or body 'help' to hecnet-request(a)lists.dfupdate.se You can reach the person managing the list at hecnet-owner(a)lists.dfupdate.se When replying, please edit your Subject line so it is more specific than "Re: Contents of HECnet digest..."

3 years, 10 months

TIMEX3 Error?

by Thomas DeBellis

An XKL monitor can stay up longer than a standard DEC or PANDA monitor. However, there is no way for a program to detect this with the TIME% JSYS. XKL defined a magic value to put into AC1 that is looked for and, if it is not there, the call is failed with a TIMEX3 error. Does anybody either know the definition of TIMEX3 or where I could get it? It's not in the PANDA MONSYM.

3 years, 10 months

Re: How long has your 20 been up?

by Thomas DeBellis

[Apologies if this is duplicate, I wasn't sure what list was active and when] Thanks for the URL, I'll put it into the enhancement list. I'm still not sure what I would put into the monitor and what would go into a light weight (or full) NTP client, but I'll have a think about it. Passing on to the Department of Pointless Programming, I 'enhanced' uptime to handle the maximum 70 bit millisecond uptime. It is: VENTI2 up for 37539161 Millennia, 7 Centuries, 2 Decades, 9 Years, 8 Weeks, 2 Days, 11 Hours, 35 Minutes, 3 Seconds and 423 Milliseconds So 37 million millennia is .../umm/... well it's a long time. In fact, at well over two and half times the current age of the universe, it may even be long enough for politicians to evolve into decent, caring, thinking individuals. The math was actually unremarkable, I changed an integer divide instruction into a routine to handle single (IDIV), double (DIV) and quadruple intermediate results (DDIV), picking the fastest divide that wouldn't overflow. The harder part was rewriting the grammatical routines to properly inflect plural noun cases. Once you get past Years, English numerological noun inflection is no longer agglutanive (like Spanish) but rather fusional, being more akin to Latin and Italian (and considered 'irregular'). So the routine did the wrong thing. A little more than half the systems programming staff at Columbia were bi-lingual, some spoke three or more languages. So it bugged us to see Unix cop-outs like "1 item(s) processed". I mean, it's a comparison and conditional transfer; an if statement--barely more than 5 minutes' work. > ------------------------------------------------------------------------ > On 1/20/22 5:21 PM, Peter Lothberg wrote: > > Time.... > >> Not quite. The acronym actually says that it is not solar time, it's >> Greenwich MEAN Time. UTC is merely the new name for GMT, obviously >> adopted to keep the French from fulminating. > > GMT was established by the Greenwich observatory observing the sun. > > When the atomic second was created the target was the year 1900 GMT > second. > > GMT is based on earth position, and it's modern equivalent is UT1, > when UTC and UT1 differs more than 0.92 sec > > we do leap seconds. > > https://www.iers.org/IERS/EN/Science/EarthRotation/UT1LOD.html > > UTC is based on a constant running timescale based on the frequency of > CS133 oscillating between two > > hyper fine states. > > So the difference between GMT and UTC can be almost a second, and > there is no system that > > distributes GMT, BTP, GPS etc are all UTC based. > > -P >

3 years, 10 months

PyDECnet T1.1

by Paul Koning

I have created a T1.1 (beta) branch of PyDECnet, which seems to be working well enough to take for a trial run. I currently have it running as the HECnet mapper node (28NH). That's not a major stress test since it's an end node. Assuming things go well I'll switch PYTHON, the area 41 backbone router, to this version in a couple of days. If anyone wants to try this, you can find the code at svn://akdesign.dyndns.org/pydecnet/branches/t1.1/pydecnet -- in other words, same Subversion server but at the branches/T1.1 subtree rather than trunk. Be sure to read CHANGES.txt, there are some small changes to the config files. And if you use the API (HTTP GET or POST to /api, in V1.0) you'll need to make changes; I dropped that approach since it wasn't workable going forward. The replacement is actually much easier and there are some support modules ("connectors") to simplify things further. See doc/api.txt for details. paul

3 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet