Tags:
create new tag
, view all tags
I'm having excessive disconnects on my dial up Internet connection -- don't know whether it's the modem, telephone line, or my ISP. This page will accumulate my learnings as I try to address the problem.

After I wrote to the expert@linux-mandrakePLEASENOSPAM.com list and got some replies, I did a Google search on ["telephone line" test] and got what appear to be some helpful links. <rant>Why is it that if I search Google first, I'm overwhelmed with useless links, but if I search it after I've asked somebody, I get good links. Hmm, don't know, but maybe it's a strategy! wink </rant>

See AboutThesePages.

UPDATE and ASIDE: I don't recall whether I've recorded this before, but sometime later I switched my second phone line (the computer phone line) to free unlimited local calling. Since then the number of disconnects has seemed to decrease significantly. Hmmmm

Update: Started a first pass at "refactoring".

Here is a pointer to the thread in the archives: OT: Testing a Modem / Telephone Line; Randy Kramer; 06/03/2002 -- I did not copy all the replies here, the next one to look at is from Jim Tarvid.

Contents

The Problem

My problem is that I get a lot of disconnects on my 33 kbps dial up line.

Several months ago, my ISP adopted a new policy -- I won't try to repeat it exactly, but basically they reserve the right to disconnect me after 4 to 12 hours (even though I pay for an "unlimited" connection). (This is in addition to whatever their policy or practice has been with respect to disconnecting an idle line after X minutes -- I run Netscape and let it check the mail every 10 minutes to avoid the idle disconnect problem.)

I get a lot more disconnects than that might indicate, and some after short periods of time, like 1 to 60 minutes. The ISP insists they are not disconnecting me, the phone line / modem is the problem.

I haven't really tackled the phone company very seriously yet, but I'm sure they will point out that their only obligation is to provide a voice grade line. Even if I insist that they test it (and possibly bill me!?!), if it tests out as adequate for voice communications, they will tell me to go pound sand.

But, I really don't know where the problem lies -- I could have a substandard modem, I could have substandard lines, or the ISP could be intentionally disconnecting me before the 4 to 12 hours. (I say that because when I first complained about excessive disconnects, my ISP rolled the disconnect policy out of their closet and said it's always been their policy, and that it was disclosed on the agreement I signed -- neither of which is true. -- I don't recall nearly as many disconnections before I gave them some static about it.)

Aside: From someone who sounds like they own or work at an ISP: "I don't terminate calls (except once per month to straighten out my RADIUS logs) but if I were to preemptively disconnect users, I wouldn't let a little traffic dissuade me."

I'm looking for suggestions on how to tackle this.

Anyone know of any sites that I can call using my modem and get some sort of report on the quality of my modem / telephone line?

Other thoughts?

PS: I would consider switching to cable or DSL, but I'm beyond the 18,000 foot limit on distance from my central telephone exchange, and my cable company is only offering one way modems at this time (in my area), which means I'd still need the modem and phone line. (Someone else suggested a sattelite link, but those are usually (?) one way also, which means I still need the modem and phone line.)

I guess I should clarify one thing -- IIRC, the ISP's policy doesn't require that I've been idle for any specified amount of time, and I don't know how they've implemented the policy. My understanding of the policy is that if they check my line any time 4 hours after I've connected they can decide that I've been "hanging" and have the right to disconnect me. (Maybe "hanging" implies the line has been idle??) A few times they've told me there is no automatic disconnect, but I just have this vague suspicion that they're not telling me everything. (And I can imagine some poor ways to implement an automatic disconnection, or creation / maintenance of a list of potential "disconnectees" presented to the "sysadmin" for use when traffic gets high. Darn, I'm way too cynical / suspicious.)

Suggestions

Try the system on another phone line

If it works well on another line it is your phone line - if not replace the modem.

Use a line you are sure of. You must control for the telephone line early or a lot of the rest of the work is guessing.

Good idea -- but not always easy to do -- I have two telephone lines at home, but, AFAIK, both pairs are in the same cable almost everywhere, including the feed to my house. I do sometimes think I hear more static on the computer line than the voice line. I did briefly try exchanging the lines (a few hours) but I'll try an extended test.

Bypass the wiring in your house

... by going directly from the telephone NIB (Network Interface Box -- that box outside your house (usually) where the telephone company makes the connection from their wiring (outside your home) to your wiring (inside the home). On modern installations, this is a plug connection (the RJ-nn plug for telephone wiring), so you can do this fairly easily.

If that improves things, your premise wiring is at least part of the problem.

Try a different modem

"In my experience, 80% of these cases go away with a good modem. Don't beat your head looking for another solution. $25 lucent actiontecs work fine (you do have to find the driver)."

"Some of the most difficult cases have been USR modems. A $5 28.8 Hayes off eBay beats any USR - new or used - for reliability."

(Aside: Jim Tarvid gets his best results from Lucent Win Modems even on Linux.)

Record the ppp log

... it may tell you the reason for disconnect.

There should be an RFC to help interpret the results. There are three common terminations - host request, user request and lost carrier. If you are getting a lot of something else, I suspect it is your ISP hanging up.

> - if you're using kppp, turn on debugging... if the telco is initiating
> the disconnect, you will see a control packet (forgot the content)
> terminating the ppp session. Otherwise, add "debug" to /etc/ppp/options
> for the same reason.

I'm not using kppp, but that is surprising -- I guess I thought they just "electrically" pressed the switchhook down. I probably don't have a good way to view those packets or maintain a lot of debug data since the gateway runs on a floppy disk -- but I might throw in an older (small hard disk) and try looking a little closer.

> - are you getting a ppp termination code? See EXIT STATUS section of
'man > pppd'...
> 0, 15 or 16 are probably what you are seeing...
> 12 or 13 should be due to your end...

Ping

... your ISP often and pay attention to the results -- they should be consistently under 200 ms. on a 33.6 modem. If they run several hundreds ms., you have errored packets. If they run several seconds you are having retrains.

OK, I ususally get 185 to 260 ms pings (skewed toward the low side), but occasionally get some 400 to 900 ms pings -- I'll have to keep watching.

Just tried slashdot.org and it timed out, pinging my ISP as www.fast.net took right around 200 ms (with the first at 203), and about 185 ms pinging my ISP by it's IP number.

(Some quotes to be integrated:

  • "We aren't looking for subtle differences. Errored packects will at least double and retrains will be several seconds (perhaps 40 or so)."
  • "Ping the RAS server or one of its neighbors. The dial-up grail is 100 ms.")

(Aside: For a moment I thought the difference might be DNS lookup time, but thinking for a minute I'm not so sure -- does a DNS lookup occur on each ping? Can it be done in 15 ms or less? I would guess not because a ping, AFAIK, is about the fastest transaction that can occur -- a DNS lookup would take as long as a ping (or two?) plus the DNS lookup overhead? Maybe the difference is due a lookup in a local DNS cache of some kind? PS: These pings were done from my Windows box -- just tried in on my Linux box (with same processor speed and much more memory) -- all times are 10 ms. or more longer!!)

I'll continue to watch and pay attention to ping times. (Just for the record, I can't / don't know how to ping from my dos box -- when I run the Gateway software the box is tied up doing that -- so these ping times are from another computer on my LAN.)

Leave your modem speaker on and listen

Send the AT command to leave the speaker on and listen for retrains -- you can hear them.

Aside: The right new modem will eliminate these problems 80% of the time.

"It is irritating but the sounds of negotiations are helpful in pre LCP diagnosis and retrains. An evening of listening to modems will teach you a lot, especially in connection with running pings."

Question: Does a retrain mean or cause a disconnect? I would hope that the modem can retrain and continue, but I don't know.

"If the retrain takes long enough - yes. Retrains are bad period."

Is the problem weather related?

"Have you noticed any difference the frequency of disconnects based on weather? E.g., is it any worse after it rains compared to an extended dry spell?"

If so, that's a good indicator of telephone line problems vs. modem or ISP hangups.

> All the suggestions provided were solid...but none would work for me. I
had > a similar problem to you but it was obvious that it was a line problem,
not > an ISP problem. Our phoneline would produce lots of static quite often.
We > noticed it was worse for a period during and after a rain. The phone
company > came out and, of course the first time, heard no static at all. Second
time, > they came out and heard the static. They replaced our old outdoor
junction > box which coincided with the termination (for a few days at least) of
static. > Finally, the static returned as strong as it always had been before and
they > came out again and located the problem...the connection from our house
into > their main line, ground level. The twisted pairs were old and the
insulation > had worn off in a few places. They fixed this and the static (and slow
modem > connection speeds and disconnects) went away.

Is the problem related to time of day?

"What about time of day? Is it any worse during the day compared to night time?"

(I assume a yes to this would point to Internet congestion problems. I certainly see those effects, but not sure they result in a disconnect (usually just overall slowness.)

Test the line with voice conversations

Listen for "static, hum, or other noise on the line? If so, you could get the phone co. to take a look at the line because your voice service is degraded."

Can you understand the word "six" when spoken -- if not it may indicate a degraded high frequency response, and can also be the basis to request that your telephone company test the line. (Thanks to

Confirm that call waiting is not enabled

(Even if you're not paying for it.)

One way to test. Establish a connection between your computer and your ISP. Then, from another phone line, dial the number of the computer line. You should get a busy signal. If you hear a ring "tone", there is some sort of problem. (But reconfirm that your computer line hasn't hung up for some other reason between the time you confirmed there was a connection and you dialed from another phone -- try this test a few times if you do get a ring tone.)

Sometimes a few minutes after a disconnect we get a (voice) call on the data line. I've sometimes (mentally) accused somebody of calling the operator to disconnect us and then put the call through, but maybe there is something like call waiting installed.

Check out your modem for available diagnostics

"Some modems track the number of transmission errors they receive, or the number of re-trains they have to do (i.e. how many times did your modem lose sync with the ISP's modem and have to re-establish the connection). You could check your modem documentation and see if any of this information is available with S regisiter queries."

Try a dial up test

"I think there are some phone numbers you can dial and get a relative quality and/or connection speed number, but I don't know any specific numbers off hand."

My Google search turned up a few that were out of service. I found one that involves sending a fax via the modem (and receiving the results via return fax). It might involve sending the fax to Australia (Queensland), and, if so, I doubt that's a useful test for my local line.

Try a real test

"There's various telephony test equipment made for testing phone lines, measuring bandwidth, etc., but you don't really want to buy that stuff for a one off test. What you need is a buddy that works for a phone company or private installation company or test equipment manufacturer that can help you test your line. As you pointed out, the phone company is not obligated to provide you high speed data service on a regular voice phone line. [In this context high speed means > 9600 baud or so.]

I'll have to look for a Telco buddy! I did find some test equipment for low cost, but you probably get what you pay for. I'm investigating these a little more.

Check your connection speeds

> This brings to mind another test to suggest whether you have a line
problem > or an ISP problem...how are your connection speeds? When I was having
the > line problems, my 57kbps modem would often be connecting at sub-20kbps
> (sometimes even 9700).

Almost every time I check, my connection occurs at 33,400 IIRC. On very rare occasions I can remember some other speeds, but that's over the 8 years or so I've been using the ISP.

> Even when it made a reasonably fast connection, the
> actual performance was much poorer than the speed would otherwise
suggest. > Even though I might get a 33kbps connection on occassion, the actual data
> transfer rate would be MUCH slower. Do you see any of this? If not,
then it > is not likely a line problem.

We often see file data transfer speeds way below 33 kbps (way below kBps or whatever that translates to) -- I've always attributed that to the Internet "hops" and, when I've looked closer, I've seen a reasonable (inverse) correlation between hops and transfer speeds, or sometimes attributed slowdowns to an overworked server. Do you have any suggestions on how to tell the difference between one of those causes and line problems? (I guess I could "bounce" a big file back and forth between me and my ISP -- I do have a 5 or 10 mB free web hosting site available.

<stopped first "refactoring" pass here>

It could be difficult to tell the difference between a lot of hither-and-yon movement of files around the internet vs simple noise requiring lots of resent packets. In my case, I concluding the slowness problem was line-noise because it was often there when we would pick up the phone (not always) and I would consistently get url load times and file transfer times and mail download times that were much slower than the connection speed would otherwise indicate. I can particularly tell the difference now that the noise was eliminated. A 42kbps connection FEELS like a proper 42kbps connection instead of a 9600. I don't get the random disconnect, and I get fewer errors and delays when accessing my pop mail.

I would think one measure of noise would show up in pings. If you select a series of sites to ping for a short while now and again, I would think that if it was a noise problem you would see lost packets. If the pings did a lot of transferring from this router to that router, taking side routes, you would get them back with slow timings and probably no loss.

praedor

On Tuesday 04 June 2002 12:44 pm, Randy Kramer wrote: > Praedor,
>
> Thanks for the response!
>
> Praedor Tempus wrote:
> > First, the obvious question...did your high disconnect problem start
> > coincident with the new policy from your ISP?
>
> It's hard to tell. I'd say it this way: I started noticing more
> disconnects (or maybe just got more frustrated with the disconnects --
> I'm not really sure which). Then I contacted the ISP, and they told me
> about this 4 hour / 12 hour policy. (I'll have to go look for this in
> writing again -- they promised to send it to me once -- they insist it
> was part of what I signed when I first signed up with them (about 8
> years ago), but it was not -- it is something they added since.
>
> So now I associate the start of the high disconnect problem with my
> "discovery" of this policy.
>
> > Though you pay for an
> > "unlimited" connection, I could see the point of you being disconnected
> > after X minutes of inactivity, so long as X isn't too short.
>
> IIRC, they always had a policy of disconnecting after X minutes of idle
> time (15?) -- this additional policy was probably in response to people
> like me who started checking for mail every 10 minutes.
>
> > All the suggestions provided were solid...but none would work for me.
I > > had a similar problem to you but it was obvious that it was a line
> > problem, not an ISP problem. Our phoneline would produce lots of
static > > quite often. We noticed it was worse for a period during and after a
> > rain. The phone company came out and, of course the first time, heard
no > > static at all. Second time, they came out and heard the static. They
> > replaced our old outdoor junction box which coincided with the
> > termination (for a few days at least) of static. Finally, the static
> > returned as strong as it always had been before and they came out again
> > and located the problem...the connection from our house into their main
> > line, ground level. The twisted pairs were old and the insulation had
> > worn off in a few places. They fixed this and the static (and slow
modem > > connection speeds and disconnects) went away.
>
> I'll switch my voice and data lines and spend more time listening.
>
> > This brings to mind another test to suggest whether you have a line
> > problem or an ISP problem...how are your connection speeds? When I was
> > having the line problems, my 57kbps modem would often be connecting at
> > sub-20kbps (sometimes even 9700).
>
> Almost every time I check, my connection occurs at 33,400 IIRC. On very
> rare occasions I can remember some other speeds, but that's over the 8
> years or so I've been using the ISP.
>
> > Even when it made a reasonably fast connection, the
> > actual performance was much poorer than the speed would otherwise
> > suggest. Even though I might get a 33kbps connection on occassion, the
> > actual data transfer rate would be MUCH slower. Do you see any of
this? > > If not, then it is not likely a line problem.
>
> We often see file data transfer speeds way below 33 kbps (way below kBps
> or whatever that translates to) -- I've always attributed that to the
> Internet "hops" and, when I've looked closer, I've seen a reasonable
> (inverse) correlation between hops and transfer speeds, or sometimes
> attributed slowdowns to an overworked server. Do you have any
> suggestions on how to tell the difference between one of those causes
> and line problems? (I guess I could "bounce" a big file back and forth
> between me and my ISP -- I do have a 5 or 10 mB free web hosting site
> available.

Udo Rader wrote:

just an idea that will very likely not solve your problem but maybe "easen" it a bit:

I don't know where you are located, but if you have access to a satellite dish, you could get yourself one of those ATSC/DVB cards that offer a satellite-downlink from your satellite dish into your computer. The uploads (=all requests you SEND to the internet) still require a dial-up line, but most of the time uploading is not the real problem. Main benefit is that the downstream is very fast (>500K).

Some of my friends have sucessfully set up such a configuration, so if you're interested in details, let me know.

Some replies to Pierre Fortin:

> - if you're using kppp, turn on debugging... if the telco is initiating
> the disconnect, you will see a control packet (forgot the content)
> terminating the ppp session. Otherwise, add "debug" to /etc/ppp/options
> for the same reason.

I'm not using kppp, but that is surprising -- I guess I thought they just "electrically" pressed the switchhook down. I probably don't have a good way to view those packets or maintain a lot of debug data since the gateway runs on a floppy disk -- but I might throw in an older (small hard disk) and try looking a little closer.

> - are you getting a ppp termination code? See EXIT STATUS section of
'man > pppd'...
> 0, 15 or 16 are probably what you are seeing...
> 12 or 13 should be due to your end...

Another reason to add a small hard disk and start saving more log data. Not sure if the dos software I'm using (iproute) provides similar termination codes. I guess long term, I should switch my internet gateway to Linux.

From Jim Tarvid:

> Jim Tarvid wrote:
> > 1) try the system on another phone line - if it works well on another
> > line it is your phone line - if not replace the modem. I get best
results > > from Lucent Win Modems even on Linux
>
> Good idea -- not sure how much difference it will make as, AFAIK, both
> pairs are in the same cable almost everywhere, including the feed to my
> house. I do sometimes think I may hear more static on the computer line
> than the voice line. I did briefly try exchanging the lines (a few
> hours) but I'll try an extended test.
>
Use a line you are sure of. You must control for the telephone line early or a lot of the rest of the work is guessing.

> > 2) bypass premise wiring by going directly from the NIB to your
computer > > - if that works it is in your premise wiring
>
> Another good idea. I'll try that, also.
>
> > 3) record the ppp log, it may tell you the reason for disconnect
>
> Good idea -- but I'm running my Internet gateway on a dos box -- it does
> have a logging facility, but I never made much sense of the logs -- I
> may try again and might even post some excerpts from the logs here and
> seem if anyone can make sense of them.
>
They are horrible but not much better in Linux. There should be an RFC to help interpret the results. There are three common terminations - host request, user request and lost carrier. If you are getting a lot of something else, I suspect it is your ISP hanging up.

I don't terminate calls (except once per month to straightenout my RADIUS logs) but if I were to preemptively disconnect users, I wouldn't let a little traffic dissuade me.

> > 4) watch pings, they should be consistently under 200 ms. on a 33.6
> > modem. If they run several hundreds ms., you have errored packets. If
> > they run several seconds you are having retrains.
>
> Hmm, I'll experiment some more with pings -- I guess you mean pings to
> local servers (like my ISP) should be under 200 ms. -- I know that
> sometimes I have very long pings for "remote" servers. Just tried
> slashdot.org and it timed out, pinging my ISP as www.fast.net took right
> around 200 ms (with the first at 203), and about 185 ms pinging my ISP
> by it's IP number.
>
Ping the RAS server or one of its neighbors. The dial-up grail is 100 ms.

> (Aside: For a moment I thought the difference might be DNS lookup time,
> but thinking for a minute I'm not so sure -- does a DNS lookup occur on
> each ping? Can it be done in 15 ms or less? I would guess not because
> a ping, AFAIK, is about the fastest transaction that can occur -- a DNS
> lookup would take as long as a ping (or two?) plus the DNS lookup
> overhead? Maybe the difference is due a lookup in a local DNS cache of
> some kind? PS: These pings were done from my Windows box -- just tried
> in on my Linux box (with same processor speed and much more memory) --
> all times are 10 ms. or more longer!!)
>
Latency in the Linux box somewhere. > I'll continue to watch and pay attention to ping times. (Just for the
> record, I can't / don't know how to ping from my dos box -- when I run
> the Gateway software the box is tied up doing that -- so these ping
> times are from another computer on my LAN.)
>
We aren't looking for subtle differences. Errored packects will at least double and retrains will be several seconds (perhaps 40 or so).

> > Send the AT command to leave the speaker on.
> > You can hear retrains. The right new modem will eliminate these
problems > > 80% of the time.
>
> Another good idea -- it sits next to my wife / near my son, but I'll
> teach them to listen for it.
>
It is irritating but the sounds of negotiations are helpful in pre LCP diagnosis and retrains. An evening of listening to modems will teach you a lot, especially in connection with running pings.

> Question: Does a retrain mean or cause a disconnect? I would hope that
> the modem can retrain and continue, but I don't know.
>
If the retrain takes long enough - yes. Retrains are bad period.

> Thanks,
> Randy Kramer

In my experience, 80% of these cases go away with a good modem. Don't beat your head looking for another solution. $25 lucent actiontecs work fine (you do have to find the driver).

Some of the most difficult cases have been USR modems. A $5 28.8 Hayes off eBay beats any USR - new or used - for reliability.

Aside: IIRC, the code to change the modem volume is atmx where x is 0 to 5, or, for some modems, 0 to 3.

Dealing with the idle disconnect

Some ISPs disconnect you after x minutes of idle time on your line. I've dealt with this for a long time by setting Netscape to check the mail every 10 minutes. Here are some other solutions:

  • If you have a dedicated dialup connection, put a ping command for 15 min intervals in cron.
  • If you have a normal dialup you can open an account on ICQ and run the LICQ applet, it pings mirabilis.com every 3 to 5 min keeping your connection alive. This is what I have to do to keep from being disconnected after 1 to 15 min.

"LICQ does only 1 ping and so, if you specify the number if pings, does ping. Example: ping 192.168.10.xxx -c1 would send just 1 ping to the address, a 5 following the -c would send 5 pings etc.."

Resources

See ResourceRecommendations. Feel free to add additional resources to these lists, but please follow the guidelines on ResourceRecommendations including ResourceRecommendations#Guidelines_for_Rating_Resources.

Recommended

  • I found a lot of potentially useful links with a google search on ["telephone line" test] -- about 86,000 hits. Some are listed in the following. I found a few for telephone line test equipment and telephone line simulators. The inexpensive equipment ($19 and $29) tested primarily for polarity -- one claims to test for line quality, and the other determines analog vs. digital -- I almost forgot about that -- there are some digital PBXs / phone lines that I've been told will destroy a "normal" modem. (The AT&T one we used at the Burns Harbor Blast Furnace Construction Office was one of those -- can't remember the name offhand.) The next step up ($119) was a test handset that sounded like it would be useful for wiretaps. Haven't done a thorough search, but no obvious listing for a cheap device to list line quality. Oops, wait -- I think the $29 device did talk about measuring line quality back to the central office -- I wonder how -- loop resistance (or impedance)?, or isolation from ground? I 'll have to find that device again. I found a few listings for telephone line tests over the phone or over the Internet (I guess) but all that I found seemed to be out-of-service at this time.

  • (rhk) Phone Line Quality and Line Noise -- Some helpful advice, especially about dealing with the telephone company (talk to them in terms of people not understanding the word "six". He's just kidding about the Slick50, though, so don't try that. The 3Com/USR phone number for the line test was not in service when I tried it on 5 June 2002.
  • (rhk) [[][]] --

Recommended for Specific Needs

A telephone line analyzer that provides fast indication of telephone line polarity, ring and line voltage levels, condition of the phone line from user's telephone to central telephone office - also can check basic telephone functions and condition of telephone line cord.
  • Quickly checks if the phone line is digital or analog, protecting your modem from damages
  • Detects over the current of the line
  • Identify safe line, polarity reverse, or open line
  • Line noise filter protection from RFI
  • Easy operation
  • Compact design for portability
  • (rhk) Transmission Level -- setting the appropriate S-registers: -- this paper describes a test to determine (primarily) your modems power output, by sending a one page fax to a number in the 300 area code. I don't know where that is, and I don't know if the test is valid no matter where you are, or only if you are somehow local to the 300 area code. (And, I didn't try the number, so I don't know if it's still valid.) The results are sent back to you as a fax, so you (I) need to be able to send and receive a fax to perform the test. On my present gateway I can't do that -- don't have appropriate (dos) software installed. After I install a hard drive on the box, I should have room to install such software. This page also contains instructions on setting your modem S registers (91 and 92) to the ideal value after performing the test. (This page was linked from http://www.mcs.net.au/telco_test.htm -- I don't know if telstra is an ISP or what.)
  • Offline Telephone Tester -- not really very applicable to this discussion, but might provide the clues I need to run a connection off line at home between two modems (i.e., without a "real" telephone line).
  • Line Noise (from Zoltrix) -- testing for line noise with the AT%Q command, also discusses connecting modem to modem without a "real" telephone line.
  • PassMark ModemTest -- Free 30 day trial, then $15 -- needs Windows and IE:
Two different test methods are provided. The first test method uses two telephone lines and two modems in a master / slave configuration. The master dials the phone number of the slave modem and after a successful connection, data packets are exchanged between the master and slave. The second test method requires only a single modem and no telephone line. A local loop back is done on the analog side of the modem, ModemTest then sends data packets which are echoed back by the modem.

Recommended by Others

  • (rhk) [[][]] --

No Recommendation

Not Recommended

  • (rhk) [[][]] --

Contributors

  • () RandyKramer - 04 Jun 2002
  • Jim Tarvid - 03 Jun 2002
  • Bill Randle - 03 Jun 2002
  • Ken Thompson - 03 Jun 2002
  • Pierre Fortin - 03 Jun 2002
  • Praedor Tempus - 04 Jun 2002
  • Udo Rader - 04 Jun 2002
  • <If you edit this page: add your name here; move this to the next line; and include your comment marker (initials), if you have created one, in parenthesis before your WikiName.>

Page Ratings

Edit | Attach | Watch | Print version | History: r9 < r8 < r7 < r6 < r5 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r9 - 2003-02-24 - RandyKramer
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by PerlCopyright 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WikiLearn? WebBottomBar">Send feedback
See TWiki's New Look