Leitch Csd 5300 Manual

Previous part

Leitch Csd-5300 Manual
Leitch Csd-5300 User Manual
Leitch Csd-5300 Manual

Leitch Csd 5300 Manual Dexterity. MTG-3901 Master Time Generator CSD-3902. Downloaded 22709 times use csd-5300. Except for use in a review, the. CSD-3901/3902 or CSD-5300 Clock System Driver Date display M/D/Y or Y/M/D (MTG-3901 Master Time Generator, CSD-3901/3902 or CSD-5300 Clock System Driver) Local offset Any amount, user selectable Display 12- or 24-hour format, HH:MM:SS or MM:SS:FF DTD-5230, DTD-5231, and DTD-5233 Installation and Operation Manual. The LEITCH CSD-3901 Master Clock System Driver allows programming of time code user bits. This facility can be used to include a specific time offset in the time code. The operating mode of one or more ADCs in a system can then be set to read this offset. A typical application is the display of GMT in addition to local time. Leitch Csd 5300 Manual Meat; Vag Com 3113 Keygen; Button Data Setup Fifa 13 Pc Download; Mission Impossible Movie Hindi Filmywap; Download Fraps FULL REGISTERED 3.2.7. Free; Digimon World 3gba; Softkey Solutions Hasp Hardlock Emulator 2009 Edge Rar; Ncomputing Vspace For Windows 7 Server 6 6 9 1 Zippyshare; Full Convert Enterprise V2 12 Full.

From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]Date: 10 Jun 1997 01:39:48 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Multicasting w/xntpd X-Keywords: auth [-/+] authentication [-/+] broadcast [-/+] delay [-/+] multicast [-/+] restrict [-/+] trustedkey [-/+]

System Administrator (SIMS) (sulis@sevilleta.unm.edu) wrote: [asking why multicast didn't connect on sparc-Solaris 2.5]

Howdy, Since sometime about xntp 3.5f, authentication is on by default and the client will reject packets that don't have a proper signature with a trusted key.

Launching with 'xntpd -A ...' will disable authentication. I have a very similar host and OS and I found I needed:

server ntp.conf added lines: keyfile /usr/local/etc/ntp.keys # chmoded 400 trustedkey 1 enable authentication # default on since 3.5f and the m-cast line would include a key item broadcast 224.0.1.1 key 1

The ntp.keys file might look like: 1 M yourkey- and I suggest using the MD5 format (which is now default in xntpdc on-line config), but the ntp.keys needs the 'M'. Since the key # is sent in the packet, everybody needs the same key in the same keyid. I got confused when I once had a 9 character key, so I now only use 8 chars now.

client ntp.conf added lines: multicast client trustedkey 1 enable authentication # default on sicne 3.5f keyfile /usr/local/etc/ntp.keys # could be NFS shared, too

Since the client sends the server an authenticated client'ish packet to measure multicast roundtrip delay time, the server seems to need the trustedkey to accept the measurement packet. The client needs it to accept the response and all the m-cast packets.

I've tried b-cast with 'disable auth' (or 'xntpd -A'), and I think it would allow m-cast to work without ntp.keys, and trustedkeys, but I worry about letting m-cast from anywhere control my time without ntp.keys. While the nearby routers won't accept foreign b-cast in (at least I hope !), as the mbone grows, I wouldn't be surprised to see alot more m-casts and I don't want my time to set without my control. I could also use restrict, but with multicasting with ip spoofing, things could be weird. I suggest using authentication for all -casts.

Bruce Bartram bbartram@etl.noaa.gov just another chimehead

From: bentson@grieg.bentson.aa.net (Randolph Bentson) Date: 11 Jun 1997 15:52:18 -0700 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Delorme anticipation [-/+]X-Keywords: Garmin [-/+] jitter [-/+] monitor [-/+] NMEA [-/+] PPS [-/+] precision [-/+]

In article <Pine.LNX.3.96.970608043719.11666A-100000@reflections.eng.mindspring.net>, Todd Graham Lewis <tlewis@mindspring.net> wrote: >Anyway, my question is, does xntpd support NMEA directly? I am somewhat >discouraged by the lack of mention of NMEA in the xntpd docs and also by >the noticeable lack of several fields from the NMEA format, esp. leap >second indication. Also, NMEA seems to be sort of gratuitous in its >message generation; the docs abound with sentences such as 'anywhere >between two and eight seconds between messages' and what not.

As others have noted, there is NMEA support but the signal from low end devices is not likely to satisfy your needs because of the jitter.

I configured my Garmin 38 as a GPS clock source. Since I already knew that the firmware was not designed to display the time on the tick, I set the precision to 1/4 second and the stratum to 15. This allowed me to monitor the clock without letting it influence my system's clock.

I have found that it reports the time approximately every 1.004 seconds. Because the NMEA code appears to assume time is reported on the tick, the offset (between this and other clocks) reports the slide. I've written a script which notes each time the offset jumps from negative to positive. Over two+ days this has ocurred nearly 500 times for an average of 470 seconds/cycle. Unfortunately the cycle interval wanders from 200 to 800 seconds with little clear pattern.

Pity. I'll have to buy another unit with the PPS signal. At $180 it's almost worth it.

(I've read one report that the Garmin 12XL, version 2.42 is better, but it's based on eyeball, not computer measurements.)

-- Randolph Bentson bentson@grieg.seaslug.org http://www.ssc.com/ssc/insidelinux

From: wiu09524@rrzc4 (Ulrich Windl) [-/+]Date: 12 Jun 1997 11:55:24 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Solaris, nsec_per_tick and NTP X-Keywords: bug [-/+] HP-UX [-/+] nsec_per_tick [-/+]

In article <339F66E7.2BD8@abm.com.au> Carl Brewer <carl@abm.com.au> writes:

> G'day again, > > As part of working out how to get xntpd 3.5.90 to work on my SPARC > ELC (Solaris 2.x), I've sent a bugreport to Sun, > stating that the default value of nsec_per_tick isn't allowing > ntpd (neither the one that comes with the OS nor 3.5.90) to sync with > some known working NTP servers. Ulrich, Harlen and > Bruce Bartram have been very helpful with my tuning efforts, and > it's now almost right (although the dispersions are still way too > large, at least now it does synchronise, and if I get some more > time, I'll play with it more and try and lock down a good value for > nsec_per_tick) > > I received a reply : > > The issue has been closed as 'not a bug'. This is because > > nsec_per_tick > > is not a kernel tunable, it reflects the number of nanseconds per > > clock > > tick. While changing this value may prove a work-around for your NTP > > problem, it will cause all sorts of timing problems elsewhere - as the > > evaluating engineer put it, 'Tuning this value would be like 'tuning' > > pi.'

If your clock is really bad _without_ NTP, simply convert your software problem into a hardware problem! Tell them: 'My system clock is out of order'. Preferrably tell them how much error it has.

Maybe tell them that HP-UX uses a very similar internal time-keeping algorithm, but has clocks with a frequency error below 10ppm. I think the trick is that they 'calibrate' their clocks prior to shipping.

Ulrich

From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]Date: 12 Jun 1997 19:27:34 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: bad syslog mesgs. X-Keywords: adjtimed [-/+] HP-UX [-/+] HPUX [-/+] syslog [-/+]

cahn (cahn@att.solutions.com) wrote: : Has anyone seen this message in their syslog before?

: Jun 11 15:38:24 nmpws105 xntpd[3879]: Can't adjust time: No such file or : directory

: On my ntp client workstation (HP-UX 9.04), the above message repeats : every 2 min. from the time xnptd started up. My npt.conf has in it : 'broadcastclient yes' and I have a startum-2 server up on my network.

: Any reply would be great.

: Charlie Ahn cahn@pdd.att.com : At&T Solutions (201) 443-2838

Howdy, This message usually seems to mean that the 'adjtimed' required by HPUX 9 versions isn't running. It might have died or wasn't started before ntpdate and xntpd in the startup script. This module comes in the xntpd distribution and 'make' does its thing on those systems.

Bruce Bartram bbartram@etl.noaa.gov just another chimehead (emailed too)

From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]Date: 16 Jun 1997 02:27:30 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: trying to setup ntp? X-Keywords: configuration [-/+] controlkey [-/+] dial [-/+] dosynctodr [-/+] driftfile [-/+] fudge [-/+] NIST [-/+] requestkey [-/+] USNO [-/+]

Mike Eggleston (mikee@spindle.net) wrote: : I'm trying to (unsuccessfully) figure out how to create a : configuration file such that I have one server as time 'master' : and all my other servers as time 'slaves'/clients. I don't : care if the slaves run xntpd or if they run ntpdate : periodically, but I want them to run *something* that sync's : the time.

: Eventually I want to sync a host of nt boxes off the time master.

: It would be nice to sync to the internet, but that's icing : to me. I must get the other servers sync'ing up. I have : the master box that runs aix4-2 and has xntpd installed on it. : For the other boxes I have the source and can compile and : install the source.

: Can anyone give me a configuration that works? I'll supply : the machine names (generous of me:). I am not sure what : things to put in and leave out of /etc/ntp.conf.

: TIA : Mike

Howdy,

I advise to start (and perhaps stay) simple. I'll use name tick for your master (a CNAME is another nice complication) and presume that you will manually adjust its clock or by tweaking (see .../html/driver1.html). To make tick able to receive these tweaks online, I need to confuse things a bit with keys. You can ignore the lines with 'key' in them at first.

tick's ntp.conf server 127.127.1.0 # local OS clock taken as a reference

# suggested complication # 1. Show the time as poorer than default fudge 127.127.1.0 stratum 9 # show poor quality

# suggested complication # 2. ntp.drift can be use to change the # the clock rate to make this host keep better time. Only # read on crank up. Written hourly by xntpd if synced to outside # source. driftfile /usr/local/etc/ntp.drift # or some such place

# suggested complication # 3. keys to allow online tweaking of # the clock rate via xtnpdc's fudge command. keyfile /usr/local/etc/ntp.keys requestkey 1 controlkey 1

tick's ntp.keys file, NOTE: use an 8 char passwd, chmod 400 ntp.keys 1 m yourpass

Client's ntp.conf server tick # tick's name or IP# driftfile /usr/local/etc/ntp.drift

Leitch Csd-5300 Manual

The drift files keep track of the difference of this host's clock and the server's time information. Each host must have its own driftfile, but the rest of the files can be NFS shared. ntp.drift can be ignore, but it will take longer for the client to wake up, and tick can't be trimmed accross a reboot, so I think you should have ntp.drift.

While I don't understand the exact details of the WinNT xntpd, the config file should be very similar except for filenames.

Add a line like server <outside public stratum 2 server name> to ntp.conf on tick to get real time it you have a network connection and restart xntpd. You could get NIST or USNO time via dial modem with a call per day (or so).

Start with just tick. Learn the tools xntpdc in general xntpdc -p to see the quick summary report ntpq like xntpdc, but another flavor NOTE: ntpq reports in milliseconds all the rest are in seconds ntpdate -d tick send 4 probes and show responses ntptrace follow the chain of servers

Don't let multiple copies of xntpd run on a single host.

You should make a launching script that gets xntpd going when the host boots. I'm on sparc-Solaris 2.5 and I'll email a copy of my overly complicated /etc/init.d/xntp script. Clients need launchers, too. There are 3 main parts: tickadj (if needed) ntpdate <server> (if such server is available) xntpd -c /usr/local/etc/ntp.conf (actually do it)

In general, you need to disable 'dosynctodr' if your host/OS has this (Sun does, I don't know about others) using the 'tickadj -s' program. I think running 'tickadj' without args (as root) will tell you about dosynctodr if you have to set it to 0 with the -s. I also suggest considering using the -A switch to set the 'tickadj' kernel variable to the best guess value.

Running ntpdate <server> in the launcher is good if there is a trustworthy server (or servers). In your first step, with tick being the only server, the client's should ntpdate tick, but tick should have this line commented out.

I like to put a few second sleep after tickadj and ntpdate in the launcher to make sure there is time for the OS to respond to the changes. Look in .../html/hints/... for specific notes about your OS. I'm presuming you have a 'recent' xntpd like ftp://ftp.udel.edu/pub/ntp/xntp3-5.90.tar.gz And you can surf http://www.eecis.udel.edu/~ntp for more background.

Bruce Bartram bbartram@etl.noaa.gov just another chimehead

From: dalton@cup.hp.deletethis.com (David Dalton) [-/+]Date: 17 Jun 1997 19:40:36 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Telecom Solutions [SymmetriComm] and NTP X-Keywords: ACTS [-/+] Bancomm [-/+] CHU [-/+] Datum [-/+] DCF [-/+] DCF77 [-/+] dialup [-/+] IRIG [-/+] Meinberg [-/+] NIST [-/+] PPS [-/+] rubidium [-/+] Spectracom [-/+] Trimble [-/+] TrueTime [-/+] USNO [-/+] WWVB [-/+]

Roy Nicholl (Roy.Nicholl@ASG.unb.ca) wrote:

:> Does anyone have experience with the Telecom Solutions DCD-LPR :>System [more specifically with the GTI-15 card, the STE2 rubidium :>oscillator (5 MHz) and the Time of Day Kit (TOD)]?

:>Their literature claims that the above assembly can provide both PRS :>and Time-of-day service. From what I can tell, the kit includes an :>RS-232/422 interface at 9600bd (8N1). The time format is :>'Year/Month/Day, hour:minute:second' with alarm fields 'severity, :>source, cause'. The TPPS is given as <1 microsecond relative to UTC.

:>From a glance over the reference clock drivers, this should work with :>NTP V3-5.90. I am looking for confirmation that someone is in fact :>using the GPS solution and any problems, etc. that may have been :>experienced in interfacing with the workstation chosen to act as the :>stratum-1.

I don't think this clock will work with NTP. Which clock driver were you thinking to use? (see list below)

When I talked to the manufacturer of this clock a few months ago they denied all knowledge of NTP. Their product is a standalone time source, a competitor to the clock+NTP+unix host that we are familiar with. It is not just a clock, and it is far more expensive than most clocks.

Nonetheless, it should be possible to write an NTP clock driver to work with the TOD feature of this beast. I just don't think it has been done yet.

-- -> My $.02 only. Not an official statement from HP. -- As far as we know, our computer has never had an undetected error. --------------------------------------------------------------------------- David Dalton dalton@cup.hp.deletethis.com 408/447-3016

ACTS - use NISTdialup clock as reference AS2201 - Austron 2200A or 2201A GPS receiver DATUM - use Datum Programmable Time System HEATH - HeathKit GC-1000 Most Accurate Clock HPGPS - HP 58503A GPS Time & Frequency receiver LEITCH - Leitch CSD 5300 Master Clock System Driver LOCAL_CLOCK - use local clock as reference MOTO - Motorola GPS clock PARSE - GENERIC refence clock driver DCF77: MeinbergDCF U/A 31, PZF 535 Schmid DCF77 receiver ELV DCF7000 Raw DCF77 signal (100/200ms pulses) HOPF 6021 GPS: Meinberg GPS 166 Trimble GPS (TAIP Protocol) Trimble GPS (TSIP Protocol) [no kernel support yet] MSF: Radio Clock RCC8000 MSF Receiver PST - PST/Traconex 1020 WWV/H receiver PTBACTS - use PTB dialup clock as reference TRAK - TRAK 8810 GPS station clock TRUETIME - Kinemetrics/TrueTime (generic) receiver WWVB - Spectracom 8170 or Netclock/2 WWVB receiver

This is a short overview for the reference clocks currently supported by xntp V3. (Ultimate wisdom can be obtained from xntpd/refclock_*.c this file was derived from that information - unfortunately some comments in the files tend to get stale - so use with caution)

Refclock address Type 127.127.0.x no clock (fails to configure) 127.127.1.x local clock - use local clock as reference 127.127.2.x no clock (fails to configure) 127.127.3.x PSTI 1010/1020 WWV Clock 127.127.4.x SPECTRACOM WWVB receiver 8170 and Netclock/2 127.127.5.x Kinimetric Truetime 468-DC GOES receiver 127.127.6.x IRIG audio decode (Sun & modified BSD audio driver) 127.127.7.x CHU Timecode (via normal receiver & Bell 103 modem) 127.127.8.x PARSE (generic driver for a bunch of DCF/GPS clocks can be extended for other clocks too) 8.0-3 Meinberg PZF535/TCXO 8.4-7 Meinberg PZF535/OCXO 8.8-11 MeinbergDCF U/A 31 8.12-15 ELV DCF7000 8.16-19 Walter Schmid DCF receiver (Kit) 8.20-23 Conrad DCF77 receiver module + level converter (Kit) 8.24-27 TimeBrick (limited availability ask time@informatik.uni-erlangen.de) 8.28-31 Meinberg GPS166 8.32-35 Trimble SV6 GPS receiver 127.127.9.x MX4200 GPS receiver 127.127.10.x Austron 2201A GPS Timing Receiver 127.127.11.x Kinemetrics Truetime OM-DC OMEGA Receiver 127.127.12.x KSI/Odetecs TPRO-S IRIG-B / TPRO-SAT GPS 127.127.13.x Leitch: CSD 5300 Master Clock System Driver 127.127.14.x MSFEES 127/127.15.x TrueTime GPS/TM-TMD 127.127.16.x Bancomm GPS/IRIG Ticktock 127.127.17.x Datum Programmable Time System 127.127.18.x NIST Modem Time Service 127.127.19.x Heath WWV Receiver 127.127.22.x PPS Clock Discipline 127.127.23.x PTB Modem Time Service 127.127.24.x USNO Modem Time Service 127.127.26.x Hewlett Packard 58503A GPS Receiver

From: per@erix.ericsson.se (Per Hedeland) [-/+]Date: 17 Jun 1997 23:36:14 GMT [-/+]Newsgroups: comp.protocols.time.ntp,comp.os.linux.hardware Subject: Re: Strange instability [-/+]X-Keywords: Arbiter [-/+] FreeBSD [-/+] jitter [-/+] Linux [-/+] PPS [-/+] stability [-/+] synchronized [-/+]

In article <5o2638$2o1$1@palladium.transmeta.com> hpa@transmeta.com (H. Peter Anvin) writes: >I am seeing the following instability when running xntpd 3.5-90.1 >(with the stability patch recently posted here) on Linux 2.0.30, >synchronized to an Arbiter GPS clock: > >[deleted] > >It appears it gains time until it loses a tick (or is it the other way >around...), and then the cycle repeats over and over again. This does >not seem to be the right thing to do. Is Linux 2.0.30 one of the >kernel versions with a broken PPL, and if so, is there a version which >is fixed?

I don't know about that, but I was seeing almost exactly the same thing (rather shorter cycle), with the same clock, on FreeBSD 2.2.1-RELEASE - here's a sample:

50595 7279.000 0.000092 -182.3694 6 50595 7342.998 0.001483 -182.3638 6 50595 7406.997 0.002803 -182.3531 6 50595 7470.996 0.004037 -182.3377 6 50595 7599.003 -0.003631 -182.3656 6 50595 7663.002 -0.002033 -182.3734 6 50595 7727.000 -0.000504 -182.3753 6

At least on FreeBSD, this appears to be an artifact of the scheduling of serial input - my knowledge of current Unix kernel internals is rather vague, but looking at the 'sio' driver in FreeBSD, it seems the interrupt handler normally calls schedsofttty() to inform the upper layers of a received character, however if it was a 'hotchar' it also calls setsofttty().

Now, the 'hotchar' is normally set to the 'end of packet' character when using SLIP or PPP, to 'reduce input latency'. I diddled the code a bit to make CR (which is the 'on time' character of the Arbiter as used by xntpd) the 'hotchar' otherwise (by default it was unset) - and the short-term variations were reduced by two orders of magnitude, from +/- 4 ms to +/- 50 us (and became rather random). Perhaps something similar can be done to the Linux driver, I'm afraid I don't have the source to that available right now.

(As an aside, I have tried this clock also with SunOS 4 and SunOS 5, and most of the variation was well below +/- 1 ms, with occasional jitter of several ms (*many* ms on SunOS 5:-() - nothing like this periodicity.)

>Secondly, the newer Arbiter models have a PPS and programmable pulse >output; one of which can be channeled to the RS-232 output. xntpd >doesn't seem to take advantage of that. Would there be a sizable >benefit to doing so, and if so, how hard would it be to add PPS >functionality to the existing clock driver?

This was (almost) trivial to use on FreeBSD, due to the TIOCDCDTIMESTAMP ioctl support present in current versions - xntpd uses this 'automagically' for *all* serial-port-connected clocks. As to the benefit, the short-term variations went down another order of magnitude or more, to +/- 2 us or so (and of course the 'hotchar' diddling wasn't needed in this case). Of course my Arbiter model only promises +/- 1 ms accuracy, so I guess this isn't very useful, but it sure looks nice on a plot.:-)

In article <5o45e5$h751@hpcc883.corp.hp.com> dalton@cup.hp.deletethis.com (David Dalton) writes: >For PPS you will need to build a 'gadget box', described in >.../htmp/gadget.html. It is a very simple bit of electronics, but not >trivial. It converts the low level PPS signal to acceptable RS232 levels.

Not with the Arbiter you don't, as Peter wrote it can produce a PPS signal on the RS-232 interface (on the DCD pin even:-) - with RS-232 levels of course, and programmable pulse width. Only problem I had was that the polarity of the pulse was the opposite of what the FreeBSD code (and I believe most PPS-handling code) was written for - pretty trivial to change when you have the source (and notice that the pulse is inverted:-), but it would be nicer if you didn't have to, of course...

--Per Hedeland per@erix.ericsson.se

From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]Date: 18 Jun 1997 17:48:44 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Fudge from system clock. X-Keywords: configuration [-/+] dial [-/+] firewall [-/+] fudge [-/+]

Edward Strike (strikee@dkbfp.co.uk) wrote: : Our site is currnetly ruinning Solaris 2.5. Is it possible to use the : system clock from on of our servers to sync the clients. This would include : NT servers and 95 clients. Do I have to get a radio clock or go out via the : internet.

: Thanks : strikee@dkbfp.co.uk

Howdy,

If you can get through the firewall to the internet or can buy a radio clock, you will have 'good time'. This is the best configuration. Dailing a modem time source, if possible, works with one or several calls per day. Internet sources will likely give leap second warnings, and some radio clocks will also.

To use the host OS time as 'good time' on the host at the top of your ntp subnet, add the following lines to its ntp.conf server 127.127.1.0 # local refclock fudge 127.127.1.0 stratum 9 # show poor quality and restart xntpd.

Leitch Csd-5300 User Manual

This won't work right if you are trying to b-cast or m-cast the time.

Since NTP is a time distribution system, you must have some source of 'good time', so you either need the internet, a radio clock, a dial modem setup, or a local refclock.

Bruce Bartram bbartram@etl.noaa.gov just another chimehead sent by email also

From: Damon Hart-Davis <dhartdav@lehman.com> [-/+]Date: Wed, 18 Jun 1997 22:05:03 +0100 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: TCP port number for NTP X-Keywords: firewall [-/+] implementation [-/+] UDP [-/+]

Brad Skeel wrote: > > Hello: > > I have read several FAQs regarding the implementation of NTP and have not > found any entries regarding the port number NTP uses. I need to know the > port number NTP uses to communicate. The enviroment I will be > impplementing NTP in is using a Sidewinder firewall and I will need to give > that port access in order to sync with an outside time source. I would > appreciate it someone could let me know.

123/UDP.

Run xntpd on your firewall as an application-level bridge, or allow through UDP traffic between port 123 on internal machines and port 123 on external machines, which is just enough to allow normal sync, though not probing with ntpq/xntpdc.

Damon

From: rstevens@noao.edu (W. Richard Stevens) Date: 19 Jun 1997 18:34:35 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: NTP and the MBone [-/+]X-Keywords: configuration [-/+] driftfile [-/+] multicast [-/+] multicastclient restrict [-/+]

I run NTP on my subnet with one 'master' server synchronizing with some 'outside' peers, and then redistributing the time using multicasting. All multicast-capable hosts just have trivial configuration file:

multicastclient 224.0.1.1 driftfile /etc/ntp.drift

Those hosts that are not multicast-capable just have a 'server' line specifying my 'master' server. This works fine.

When I bring up my MBone connection (I get charged by usage on my frame relay Internet connection, so I only turn on mrouted when necessary) I notice the multicast clients have about a dozen hosts that they are receiving multicasts from, some from Europe. Watching the network with tcpdump shows lots of NTP traffic to these sites, even after I bring my MBone link down. About an hour I after the link is down I see the reachability go to 0 but there is still NTP traffic to these sites.

I notice that when my 'master' multicasts on the local subnet, the TTL is 1, as I would expect, so I would guess these other sites have set the TTL way up in their configuration file.

My feeling is that no site should be sending NTP *multicasts* outside their 'site' ('link-local', 'site-local', or 'organization-local' should be the limits for the scope, in IPv6 multicasting-speak, but never 'global'). Is this reasonable? Or should stratum 1 servers multicast to the world? (I notice only one of these sites is a stratum 1 server in the list that's going across the MBone today.)

I would guess the only way around this is to add some 'restrict' lines to my multicast client's configuration files, to ignore anyone not on the local subnet? Or should NTP default to only accept multicasts from hosts on the local net?

Rich Stevens

From: wiu09524@rrzc4 (Ulrich Windl) [-/+]Date: 20 Jun 1997 09:50:40 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: ntp logging query X-Keywords: monitor [-/+]

In article <EBzJL1.Io1@gpu.utcc.utoronto.ca> russ@doghaus.uucp (Russell Sutherland) writes:

> I am attempting to log all ntp transactions from other machines which > have mine configured as a 'server'. At present my logging only keeps > track of 'peers'.

With 'enable monitor' and 'monlist' in xntpdc you get some information, but not all...

Ulrich

From: bwb@etl.noaa.gov (Bruce Bartram) [-/+]Date: 20 Jun 1997 18:57:38 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: invalid packet header X-Keywords: authentication [-/+] dispersion [-/+] FAQ [-/+] fudge [-/+] LCL peer [-/+]

Falko Poiker (fpoiker@starvision.com) wrote: : I have a rather simple setup that doesn't work. At this point I have 3 : workstations that I'm trying to sync up using NTP. Once that works, I : plan on sync'ing it with the outside world...

: Anyway, I have 1 workstation running as a server and the other two : running as clients. Everything seems to work fine except for the fact : that no clock adjustments are taking place. The debug option of xntpd : indicates that the clients are receiving 'invalid packet header's from : the server. I've checked the docs and the FAQ, but I can't seem to find : that particular error anywhere. Has anyone run into this problem : before?

: Please email me your responses, I don't check this newsgroup all that : often.

: Thanks! : Falko Poiker : fpoiker@starvision.com

Howdy,

Does your master (which I'll call 'tick') have a refclock ? NTP is a time distribution system and it must have a refclock somewhere. The crude way of using tick's own OS clock as a reference is to add server 127.127.1.0 # local refclock fallback fudge 127.127.1.0 stratum 9 # show poor quality to tick's ntp.conf, then kill and restart xntpd on tick.

Tick will now answer clients. Try 'ntptrace' on tick to see if tick is at stratum 10 with reference 'LCL'.

The debug lines tend to require looking at the source code. To find your report I did cd xntpd grep 'invalid packet' *.c to find the error message is from ntp.proto.c. Looking at the line lead me to .../include/ntp.h section on flash code #define TEST5 0x10 /* peerauthentication failed */ #define TEST6 0x20 /* peer clock unsynchronized */ #define TEST7 0x40 /* peer stratum out of bounds */ #define TEST8 0x80 /* root delay/dispersion bounds check */ so I think you probably got the TEST6 with code 0x20.

Bruce Bartram bbartram@etl.noaa.gov just another chimehead email sent also

From: Damon Hart-Davis <dhartdav@lehman.com> [-/+]Date: Fri, 20 Jun 1997 12:03:01 +0100 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: NTP and the MBone [-/+]X-Keywords: configuration [-/+] delay [-/+] multicast [-/+] restrict [-/+]

W. Richard Stevens wrote: > > I run NTP on my subnet with one 'master' server synchronizing with some > 'outside' peers, and then redistributing the time using multicasting.

...

> I notice that when my 'master' multicasts on the local subnet, the TTL > is 1, as I would expect, so I would guess these other sites have set > the TTL way up in their configuration file. > > My feeling is that no site should be sending NTP *multicasts* outside > their 'site' ('link-local', 'site-local', or 'organization-local' > should be the limits for the scope, in IPv6 multicasting-speak, but > never 'global'). Is this reasonable? Or should stratum 1 servers

I think that is reasonable...

> multicast to the world? (I notice only one of these sites is a

I think that that would also be reasonable, though possibly with a hop count of (say) 10 to avoid really distant hosts getting poor time over long-delay paths...

> stratum 1 server in the list that's going across the MBone today.) > > I would guess the only way around this is to add some 'restrict' lines > to my multicast client's configuration files, to ignore anyone not on > the local subnet? Or should NTP default to only accept multicasts > from hosts on the local net?

I *always* use restrict to minimise spoofing dangers...

Damon

From: Damon Hart-Davis <dhartdav@lehman.com> [-/+]Date: Fri, 20 Jun 1997 16:09:16 +0100 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: NTP Software for Solaris

Antonio J. Diaz Chinea wrote: > > Hi, > > i'm trying that the xntp read a GPS signal by a serial port on a sun > machine with Solaris 2.5.1. All references are for SunOS 4.x, I'm > attempting with the driver 8, but the xntp give somes errors: > PARSE receiver #0: stream_init: ioctl(fd, I_PUSH, 'parse'): Invalid > argument

Just means you have not built and installed the PARSE driver.

xntpd should work without, though may be less accurate.

Damon

From: wiu09524@rrzc4 (Ulrich Windl) [-/+]Date: 24 Jun 1997 10:32:10 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: more on xntpd delay X-Keywords: poll [-/+] synchronized [-/+]

In article <01bc8021$d3be2020$ed9392c0@nt-bxh> 'bjoern' <bxh@dsc.com> writes:

> I run xntp3-5.90, as a local time server on an NT-machine, and a client on > Solaris. If I have the daemons running on both sides even for hours, a > manual change on either clock (5 minutes) will take 5-10 for the client to > resynchronize.

> > I thought that should have been done within 64 seconds (I didn't change the > default polling interval)?

xntp polls reference clocks at 64 seconds minimum (by default) or at a longer interval. At each poll data is accumulated to build an estimate of the true time. With 64 seconds this takes typically 5 minutes until xntpd synchronizes.

NTP does not expect the true time to change other than estimated. If you set your reference clock manually, xntpd will typically lose synchronization after about 5 minutes. After another 5 minutes it will synchronize again, typically stepping time, and thus losing synchronization again. After still another 5 minutes xntpd will have synchronized.

Ulrich Windl

> > Does anybody know why it takes longer than it should? > > > Thanks, Bjoern > > bxh@dsc.com

From: Damon at play <dhd@-exnet.com> [-/+]Date: Mon, 23 Jun 1997 09:34:35 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: signal sources [-/+]X-Keywords: authentication [-/+]

ZWORF wrote: > > Is anyone else out there concerned that they might be running their > corporate network time services off of an Internet signal?

Slightly.

> I don't have problems with compiling/firewalling/installation or syncing, > just the idea that our business 'might' be susceptible to a signal source > of dubious origin, aka a time server of stratum 1. > There's probably some authentication built-in to the signalling mechanism. > Am I too worried, and should I just forget about it and install and use

I think you are right to worry, though if you take time from several sources you will reduce the risk of accidental calamity, and if you use the restriction and authentication mechanisms you will reduce the chance of deliberate harm almost out of sight.

Further, you can buy a cheap radio clock as your preferred source of time. Eg look at my page:

http://www2.exnet.com/NTP/ARC/ARC.html

for a clock for about GBP100 within +/- 10ms of true atomic time and with full support now included in xntpd 3-5.90.1 B^>

Just have the net sources validate your local source of time, and you can probably rest quite easily if you have taken the other steps above.

Regards,

Damon

-- Damon s0dhd@exnet.com, d@hd.org REMOVE `-' FROM RETURN ADDRESS TO REMOVE ANTI-SPAM FEATURE http://www2.exnet.com/ http://www.exnet.com/CV/DHDCV.html Public NTP time server: http://www2.exnet.com/NTP.html

From: hpa@transmeta.com (H. Peter Anvin) [-/+]Date: 18 Jun 1997 02:41:47 GMT [-/+]Newsgroups: comp.protocols.time.ntp,comp.os.linux.hardware Subject: Re: Strange instability [-/+]X-Keywords: antenna [-/+] Arbiter [-/+] FreeBSD [-/+] Linux [-/+] PPS [-/+] precision [-/+] release [-/+]

Followup to: <5o771e$dlc$1@news.du.etx.ericsson.se> By author: per@erix.ericsson.se (Per Hedeland) In newsgroup: comp.protocols.time.ntp > > > >It appears it gains time until it loses a tick (or is it the other way > >around...), and then the cycle repeats over and over again. This does > >not seem to be the right thing to do. Is Linux 2.0.30 one of the > >kernel versions with a broken PPL, and if so, is there a version which > >is fixed? >

Okay, it seems to happen with just about every Linuxrelease. A guess is that it might have been a problem with the fast Pentium timer; we'll see...

> >Secondly, the newer Arbiter models have a PPS and programmable pulse > >output; one of which can be channeled to the RS-232 output. xntpd > >doesn't seem to take advantage of that. Would there be a sizable > >benefit to doing so, and if so, how hard would it be to add PPS > >functionality to the existing clock driver? > > This was (almost) trivial to use on FreeBSD, due to the TIOCDCDTIMESTAMP > ioctl support present in current versions - xntpd uses this > 'automagically' for *all* serial-port-connected clocks. As to the > benefit, the short-term variations went down another order of magnitude > or more, to +/- 2 us or so (and of course the 'hotchar' diddling wasn't > needed in this case). Of course my Arbiter model only promises +/- 1 ms > accuracy, so I guess this isn't very useful, but it sure looks nice on a > plot.:-)

Okay; I got some patches from Ulrich Windl that implements PPS support in Linux; the error remains (it loses exacly one tick every 400 or 416 seconds) although the PPS input helped the kernel recover sooner.

> Not with the Arbiter you don't, as Peter wrote it can produce a PPS > signal on the RS-232 interface (on the DCD pin even:-) - with RS-232 > levels of course, and programmable pulse width. Only problem I had was > that the polarity of the pulse was the opposite of what the FreeBSD code > (and I believe most PPS-handling code) was written for - pretty trivial > to change when you have the source (and notice that the pulse is > inverted:-), but it would be nicer if you didn't have to, of course...

Actually on the DSR pin, which connects to DCD when you connect it to the computer via a standard null modem. Overall I have to say the Arbiter unit is very nice -- for another few hundred US$ you can get an add-on module with RAIM that increases precision to 1 µs; with that, the antenna gear and the backup battery it still came to under US$1,200 which is quite acceptable...

-hpa -- PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74 See http://www.zytor.com/~hpa/ for web page and full PGP public key Always looking for a few good BOsFH. ** Linux - the OS of global cooperation I am Baha'i -- ask me about it or see http://www.bahai.org/

From: 'Greg' <schueman@ix.netcom.com> [-/+]Date: 21 Jun 1997 04:38:05 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: WinNT NTP and Time Zone? X-Keywords: configuration [-/+]

Brian, Grab the latest version XNTP 3-5.90.1b from ftp.drcoffsite.com and let me know whether the problem still exists. The _ftime() function was causing Day Light Savings time problems, and I wonder whether it might have other problems related to time zones.

Send email to <access@drcoffsite.com> for access to the site. The latest NT for Intel binaries are there.

-Greg

Brian L. Bowers <bowers@mtm.syr.lmco.com> wrote in article <33ABBE7A.469C@mtm.syr.lmco.com>... > I am having difficulty trying to establish NTP time distribution for a > system being installed in Singapore, Time Zone (GMT+8:00)Hong Kong, > Perth, Singapore, Taipei. I am using the WinNT version 3.87 port of > NTP, and utilizing the Local Clock driver on the WinNT NTP server. When > the WinNT NTP server PC is set with the Singapore time zone, the time > being served to the rest of the NTP clients is 15 hours off. > > In fact, while recreating the problem here, back on the East coast USA, > it appears that a server with a time zone outside of the continental US > causes similar problems. The simple test can be run to see if any one > else is seeing this problem. > > Take two 2 WinNT PCs with the 3.87 WinNT port of NTP installed. > Set the two PC’s time zones to Eastern Time. > Start one of the PC daemons with the ntp.conf file containing the > following line: > server 127.127.1.0 > wait for the NTP to claim synchronization to Local Clock. > Go to the second PC and use a Command Prompt window to perform an > ntpdate to synch from the first PC. > Things should look fine. > > If you set the second PC to use the Time zone to (GMT+8:00)Hong Kong, > Perth, Singapore, Taipei and do an ntpdate to the first PC, which is > still EST, things still look fine. > > Now try it after setting the Time Zone on the server to (GMT+8:00)Hong > Kong, Perth, Singapore, Taipei, or even Hawaii. Restart the server > daemon. Now when you use ntpdate to the first PC it doesn’t work, the > two PC are not showing the same time, local or GMT. > > 1) Does anyone else see this occurrence? > 2) Is there a configuration parameter that I am missing? > 3) Why does NTP know anything at all about time zone, or is it just the > Local Clock driver. > 4) Why do I get the error “time error -53999.973000 is way too large > (set clock manually)” if I try to synch a Singapore Time zoned PC to a > Eastern Time zoned PC? > > > Brian Bowers bowers@mtm.syr.lmco.com > Lockheed Martin (315) 456 - 1036 > Syracuse NY 13090 (315) 456 - 1207 fax >

From: edesio@acm.org [-/+]Date: Wed, 25 Jun 1997 14:12:54 -0600 [-/+]Newsgroups: comp.protocols.time.ntp Subject: TAPR TAC-2 (Totally Accurate Clock) [-/+]

TAPR TAC-2 (Totally Accurate Clock) is now available! Take a look at http://www.tapr.org/tapr/html/tac2.html

------------------- Posted via Deja News ----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet

From: hpa@transmeta.com (H. Peter Anvin) [-/+]Date: 23 Jun 1997 23:32:41 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: signal sources [-/+]X-Keywords: antenna [-/+] Arbiter [-/+] authentication [-/+] Linux [-/+] PPS [-/+] release [-/+] stability [-/+]

Followup to: <33AE432B.201F@-exnet.com> By author: Damon at play <dhd@-exnet.com> In newsgroup: comp.protocols.time.ntp > > I think you are right to worry, though if you take time > from several sources you will reduce the risk of accidental > calamity, and if you use the restriction and authentication > mechanisms you will reduce the chance of deliberate harm > almost out of sight. > > Further, you can buy a cheap radio clock as your preferred > source of time. Eg look at my page: > > http://www2.exnet.com/NTP/ARC/ARC.html > > for a clock for about GBP100 within +/- 10ms of true atomic > time and with full support now included in xntpd 3-5.90.1 B^> > > Just have the net sources validate your local source of time, > and you can probably rest quite easily if you have taken the > other steps above. >

Be careful with stability; however -- xntp seems to go quite ballistic when the stability of the source isn't good, even if it stays within a moderately tight range around the proper value.

Leitch Csd-5300 Manual

A somewhat more pricey clock, but one which we have just gotten working and which seems to be really good is the Arbiter series of GPS clocks. The one we have is the 1092A tabletop model with the RAIM module; claimed accuracy 1 µs. It has RS-232 output which includes programmable pulse (can be used for PPS) on the DSR line (which becomes DCD when connecting via a standard null modem.)

With all the antenna gear and battery backup it ended up around US$ 1,100.

This clock is good enough to use as a primary receiver. We are getting accuracies in the microsecond range using a Linux box with a somewhat patched kernel as the xntpd host; I'm planning to finish the patches for release pretty soon.

-hpa

-- PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74 See http://www.zytor.com/~hpa/ for web page and full PGP public key Always looking for a few good BOsFH. ** Linux - the OS of global cooperation I am Baha'i -- ask me about it or see http://www.bahai.org/

From: edesio@acm.org [-/+]Date: Wed, 25 Jun 1997 14:12:54 -0600 [-/+]Newsgroups: comp.protocols.time.ntp Subject: TAPR TAC-2 (Totally Accurate Clock) [-/+]

TAPR TAC-2 (Totally Accurate Clock) is now available! Take a look at http://www.tapr.org/tapr/html/tac2.html

------------------- Posted via Deja News ----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet

From: hpa@transmeta.com (H. Peter Anvin) [-/+]Date: 26 Jun 1997 20:48:15 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Linux timekeeping patch X-Keywords: Arbiter [-/+] Linux [-/+] PPS [-/+]

I have integrated Ulrich Windl's PPS patch for Linux with support for BSD-style TIOCDCDTIMESTAMP serial ioctl(). A preliminary patch against 2.1.44-pre3 is available at:

ftp://ftp.kernel.org/pub/linux/kernel/hpa/timekeep-2.1.44-pre3.tar.gz

It includes a program to enable and set the polarity of the PPS discipline (the latter was an addition of mine after finding out the polarity of my radio clock was the opposite of what you would expect.)

Note that this patch is only useful if you have a hardware time source connected via the serial port; network NTP is not affected.

I have used an Arbiter 1092A radio clock with RAIM as the test device; the claimed accuracy of the device is =B11 =B5s. Preliminary results are very good. I would very much like to know from other people what their results are.

NOTE: you must recompile xntp after installing these kernel sources in order to take advantage the changes! I highly recommend getting the latest version of xntp (3-5.90.1) from ftp.udel.edu.

Most of the work on this patch was done by Ulrich; I merely ported his code to 2.1.44-pre3, added TIOCDCDTIMESTAMP and tidied up the integration.

From: wiu09524@rrzc4 (Ulrich Windl) [-/+]Date: 03 Jul 1997 09:38:53 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Authenticated ntpq commands cause core-dump in xntpd X-Keywords: DCF77 [-/+]

In article <5pbus9$fuu@gsms01.alcatel.com.au> jeremyp@gsms01.alcatel.com.au (Peter Jeremy) writes:

> (*) I hadn't seen any incoming leap warning from any upstream feeds by > a couple of hours before 0000UT and thought they had all forgotten.

DCF77 just announces a leap second one hour before it happens. with 1024s of polling interval it would only get 3 hops along. With 4096 seconds it won't be recognized at all. I don't know where other leap second announces can come from, but that is definitely a problem for DCF77.

Ulrich Windl

From: jcs@zoo.bt.co.uk (John Sager) [-/+]Date: 30 Jun 1997 12:32:00 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: Inexpensize Radios? X-Keywords: NMEA [-/+] resolution [-/+]

In article <Pine.LNX.3.96.970630071104.10645R-100000@reflections.eng.mindspring.net>, Todd Graham Lewis <tlewis@mindspring.net> writes: : On Mon, 30 Jun 1997, W. H. Gilmore wrote: : : > I have heard though I don't believe it : > that there are 'good' devices to be had in the $200 range. Please : > wake me up if I'm in a dream. : : My Delorme Tripmate has been very picky about receiving GPS signal, to the : point of being bothersome. However, at $150, it was a steal. It : generates NMEA, so the accuracy leaves something to be desired, but it's : GPS.

Off the shelf handheld GPS receivers aren't worth considering as NTP Stratum 1 references. The NMEA output has no timing reference information, so, although it tells you time of last fix, you have no idea when that happened relative to the output of the message. If you use GPS, then you need access to the 1 pulse-per-second output. Even then, some receivers do/did not output the pulse 'on the mark'. Part of the message output was an offset within the second of the pulse time from UTC, and the resolution of this offset field was limited to about 1 millisecond. It is possible to get low-cost GPS engines, but not down in the $200 range when you include all the interfacing. Try http://www.tapr.org/tapr/html/tac2.html for one possible solution.

J

From: pausch@electra.saaf.se (Paul Schlyter) [-/+]Date: 7 Jul 1997 11:04:50 +0200 [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: time zone names

In article <01bc8903$759f1b80$0605eecd@edsawick>, Ed Sawicki <ed@alcpress.com> wrote:

> This rather complex system of timekeeping is what results when > governments dictate the rules for time rather than the scientific > community. If it were up to me, there would be no Daylight Savings > Time and no time zones. The entire planet should simply use UTC. > > UTC is 'Universal Coordinated Time' (in English) and for most > purposes is the same as Greenwich Mean Time (GMT).

GMT is ambiguous and obsolete, and should be avoided. Today, GMT is usually used to mean UTC. Earlier, GMT was used to mean UT2.

Please stick to the precisely defined terms UTC, UT0, UT1 and UT2. If an accuracy better than one second is not needed, one need not distinguish between them; then one can say GMT, or why not simply UT?

-- ---------------------------------------------------------------- Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF) Grev Turegatan 40, S-114 38 Stockholm, SWEDEN e-mail: pausch@saaf.se paul.schlyter@ausys.se paul@inorbit.com WWW: http://spitfire.ausys.se/psr -- updated daily!

From: 'Greg' <schueman@ix.netcom.com> [-/+]Date: 8 Jul 1997 05:47:31 GMT [-/+]Newsgroups: comp.protocols.time.ntp Subject: Re: GPS Time Sync for Windows NT X-Keywords: Datum [-/+] Windows [-/+]

Look at one of the vendors who has a network attached GPS receiver, such as True Time, Datum, et al... Then grab the latest XNTP for NT binaries from ftp.drcoffsite.com and off you go. Send email to <access@drcoffsite.com> to get instructions how to login to the site.

-Greg

Martin Marshall <marshalm@ebrd.com> wrote in article <5pqfja$slf$1@ldn2mx1.ebrd.com>... > Hi, > > I require to install some time scyn servers in our Restident offices (Based > in Europe), can anyone recommend a GPS attachment and software for a > Windows NT Server. > > It has to be a near zero admin as possible. > > Thanks in advance, > Martin Marshall > > >

Next part

User Manual, GSI Tympstar V2. Product Code: 2000-0120. Other Product Code: 8012153. Manufacturer: Grason Stadler. Instruction Manual, GSI Tympstar V2. Maico easy tymp quick user guide - Free download maico easy tymp quick user guide PDF PDF Manuals Library MAICO EASY TYMP QUICK USER GUIDE PDF Books are an integral part of a human's' life. Timpan metro, tympstar, gsi, especificaciones de - MedWOW / Equipo M dico / Otorrinolaringolog a / Timpan metro / Gsi / Tympstar / Especificaciones del.

GSI TympStar Pro Clinical Middle-Ear Analyzer The GSI TympStar Pro is the ideal solution for a broad patient population. Protocols may be configured to optimize efficiency and workflow; the flexibility of pre-defined protocols saves time and creates consistency in testing procedures. Each TympStar Pro is equipped with three probe tones, 226, 678 and 1000 Hz, to address the diagnostic challenges of every patient.

Simultaneously record and store multiple tympanometry admittance (Y/B/G) for each tracing and determine if abnormal tympanogram is the result of tympanic membrane defect or ossicular chain disorder. Evaluate neural integrity with complete confidence using the multiplex pulsed-tone stimulus for reflex threshold testing. The enhanced threshold seek function displays all reflex intensities and provides multiple options to evaluate reflex growth. Seamlessly move through the neural integrity evaluation while saving time and observing responses in real time.

Save for Bully Scholarship Edition. Post Views: 135,751. Savegame for Bully Scholarship Edition The game passed by 100%! – Complete all story missions. My Documents Bully Scholarship Edition Download save. Also, you can download trainers for this game. Comments: Tweets by @savesforgames. If you are ready to upgrade your game, click on Game Save and don’t wait a second more! Save Game file download option is a perfect choice – you will get great improvement for your game version. No more worries about the lost battles – it’s a way to fix all the mistakes within few clicks! Bully scholarship edition save file chapter 4 download free.