New proposal:
So you've all read the previous ISDN proposal, here's the next one:
Dual channel ISDN from behind the t1 that I'll have at home about
the beginning of september. My t1 will be to a dual-homed hub between
digex and michnet. This proposal is independent of CICNet and/or any of
my future employers. Here's what you'd have to do:
Order an ISDN line on your centrex into the pumpkin
Order an ISDN line on your centrex to my place of residence (Haven't
found one yet, ugly long story, but it'll be in a2).
Get two pipeline 50's (or whatever you want), attach them to my
ethernet port, and I'll route you some ips.
Comments? I can go into technical details elsewhere as to exactly
how this will work, along with possible network diagrams, etc..
68 responses total.
It's a generous offer.
This response has been erased.
Terrific offer.
That really depends on the place that I find, I need to keep looking before my sublet runs out in another month.. More details once I sign a lease..
This certainly seems like a great offer. I've got the same questions that Valerie asked about stability of where you're going to be living, and also questions about the stability of the deal giving you the T1. Is that deal such that you could discuss it publicly, or is that something better discussed in private?
I can discuss publically where my t1 will go, but other network details past that router are kinda tricky and complicated.. My t1 will go to dorians t1 he has at home, and he will be dual homed (at least) between a few providers.. I can draw a map at the BoD mtg or afterwards, etc. for people to look at.
Very nice!!
I don't know what you mean by "dual homed". Does that mean that if Michnet stays poorly connected to the net, you'll be linked to both Michnet and a less poorly connected provider? Who is dorians? Would grex have to trust him to not packet sniff grexers' passwords?
I give you my word that I and Dorian don't have the time to waste sniffing grex passwords for grins and giggles of breaking into peoples accounts. At the BoD meeting, the connectivity was explained, here it is in technical terms: Dorian will be dual-homed (connected to two ISPS) speaking eBGP to both of them, so packets to grex will take the shortest ASN path to get to grex, and the same outbound shortest ASN path will be taken also to return your packets to the site. Non techie terms: Grex's ISP will have two major backbone ISP connections (initally), and be able to be reached as long as nothing bad happens to any of the direct-connect phone lines that will interconnect dorian's and my houses together.
In other words, Jared and Dorian will be a lot better connected than most local ISPs are.
BTW, i do understand the need to bring up the security of the networks that you will be attached to... Please feel free to bring up any more you might have either in e-mail or here.. to give you a brief idea of what I'll be doing (by default), is source filtering, and spoofing filtering.. that's not really a discussion here, but notable since those tend to be the typical attacks you might see in either direction, either from grex out or elsewhere in.
Hello Jared Mauch, can you explain the router/modem required for connection? Perhaps you can send uuencoded pictutres in several parts? Perhaps I can get some real estate investment in Michigan?/Property? Regards ( AW)
For a picture of an Ascend P50, see http://www.ascend.com/202.html.
yup
Can anyone give us a reasonable estimate of a date by which our new ISDN line will be open for users?
Being a pesimist, I expect the ISDN link to be up and running in one month. It would be reasonable to expect it sooner.
Ameritech has installed the lines at both ends. I'm planning to wire from the Pumpkin's phone room to the Pumpkin sometime this weekend. The person doing the wiring on the other end should be doing it sometime in the next week, I think. After that, it will be a matter of configuring the routers and plugging them in. Once I get my hands on the routers that probably means about half an hour or an hour of work. I think they were ordered yesterday, so they should be showing up any time.
Sounds right. The most optimistic estimate would be sometime in the latter half of this week.
This response has been erased.
I can probally get the connection up a bit sooner even without dorioans end being done by passing it to unused isdn lines at work even for just outgoing traffic
I have a question that I don't believe has been answered: Will we be increasing the number of telnet ports available when the new connection is installed?
I hope so, then we can tal about losing the damn countdown que!
Amen to that.
I doubt we'll ever get rid of the queue, since any increase in telnet ports will eventually be swallowed up by increased usage. (I remember when 48 ports seemed like way too many...) Hopefully an increase in ports will at least mean that we won't see the queue used for a while.
In addition to the bandwidth problems, there are also system resource problems with increasing the number of telnet ports too much. We should discuss that when the new connection goes in. I won't say we definitely should increase the number of telnet ports right away with the new connection, but we certainly should once we have the new computer online. Richard, do you have a better solution for handling situations where we have more users wanting to get on than we can support? Please explain, in detail, how it would be implemented and what advantages *and disadvantages* it would be likely to have.
Right. I basically could not ever get in, at all, via telnet before the queue. I suppose I could write a Procomm script that would attack-telnet, but that hardly seems like a better solution.
This was discussed in another item. Basically the conclusion was that we will probably increase the number of people who can simultaneously telnet in, but we will not eliminate the queue. The increase in the number of slots will be modest at first. We need to see how well Grex's CPU can handle the added load. If we can get the 670 running as well, we will be able to make more substantial increases.
This response has been erased.
#24...see I dont or didnt knwo this...I never had a problem telnetting in prior to the countdown...neverused any programs or anything...rarely ever got the "all ports are busy" And if I did, it was just an extra clicl of the mouse to get right back in. I had worse problems telnetting into mnet than I neverhad into here. Now I come on in the morning and Im number forty in the countdown and get timed out half the time when I get to ogin because I dont want to stare atmy grex screen like a zombie waiting for the que.
i hated the old system... took me ages, if I got in at all. essentially, I had no choice but to telnet to grex every five seconds waiting for a port to free up. At least with the queue I can leave for a bit.
This response has been erased.
I also have never run into the problem of telnet not accepting me prior to the queue. Now I dial in almost all the time, so this really doesn't affect me much, but...
There may be some modicum of truth to that. With the old system, if people got "all ports busy" a few times, they probably went away. Now, if they get "you are number 10 in the queue" they are more likely to wait around and eventually log on. More people logging on means more people on the system, so the periods of full utilization are longer than they used to be. Basically, if you make it easier to wait for a connection, more people will wait, so there will be fewer times when there is no wait. This definately means better utilization of Grex, with more users on more of the time, but it could lead to the perception that Richard and Orinoco report of Grex being harder to get onto.
#33...thats what I mean, if it increases usage load overrall then the que defeats its own purpose. Plus nobody wanting to run new use is going to wait around if they are down in the que somewher like fifteen or twenty. At some point, the curiousity factor is outweighed by the time/trouble it takes to get in. check how often new user was run on average before the que was installed against how often it is run now...bet you'll find a difference
This response has been erased.
Re #34: You miss the point of the queue, Richard - the point was to be more fair to people trying to telnet in, the same way that it's fairer (and more civilized) to stand in line at the bank that it is to mob the tellers, with the biggest person getting in first.
Yep, and the manager(s) of the bank should ignore the ranting of the big people. >8)
That's funny, my rampant use of newuser has slowed down quite a bit :)
This response has been erased.
Actually, if the queue is causing grex to be used more fully more of the time, then I would maintain that it is working great. I would be happy of grex was full *all* of the time.
This response has been erased.
Because that would mean that people are using it. (Okay, so that's obvious, but...) It means that Grex still has room to grow, that people are communicating. It means that Grex is a little slower, and so it increases the effect of that filter that selects for people who *like* it here, rather than people who use Grex just for email. It means a higher chance that people will wander into conferences, and so more people to talk to here. It makes me feel better about donating my time to Grex. Afterall, I probably wouldn't want to donate my time to a system that isn't used. It means that I feel better about donating money for better hardware and better internet connections. They're likely to be used. I've never said to myself "I think I won't Grex today, because it's too slow." I have a multitasking computer, and a multitasking brain. If Grex is slow, I do something else while I'm waiting. So, more people on Grex is a good thing, in my opinion. If there's a time of day when not many Americans are on, I'm happy to see people of other nationalities from other parts of the planet filling Grex up. This is also why I think the queue is a great thing. It allows everyone equal access to Grex, even while Grex is full. It allows Grex to be fuller.
Amen, Daniel!
Well, *most* of the time lately Grex hasn't been slow enough to scare people off, I think. But there comes a point when that *is* an issue, somewhere before you start getting 10-second lag for every character you type.
I've only occasionally been "scared" off of grex when lag is really, really bad, usually because there's very little else to do due to computer problems of my own and because I'm spoiled by dialin speeds. I usually multitask my eyes out when I'm bored. It works for me, and I'm not the only one who does it.
This response has been erased.
I've had to do it; It's annoying.
This response has been erased.
Hopping into and out of mail on grex, its like wearing twenty pound weights on each leg. You can do it, but it is unbearably slow. I cant imagine using grex for my regular email...I type so fast that grex (or rather Pine on grex on rare occasions when I use it) takes forever to catch up. I've found myself three and four paragraphs ahead. I wouldnt recommend grex for email to anyone...use a .forward file and do email elsewhere, even if its m-net or nether or some horribly over-commercialized place on the web like Hotmail. Grex has to be one of the worst places to do email on the entire 'net.
Of course once grex is ISDN-connected, that may change. (I actually multi-tasked grex this morning...I hadnt read Agora in two days and had 25 items to read, so I did a Backtalk vs. Picospan contest and ran Agora on both at the same time, just to see which got me through it faster. And..drum roll...Backtalk won. Normally Picospan would've won easily but I guess it was a bad morning to be telnetting *shrug*)
Richard, Grex can do mail faster, with a different mail program. Pine is the slowest thing ever written. "mail" (the program) may be less friendly, but it is a heck of a lot faster.
Yeah, I've always used mail, and it's slow to load, but no slower than anything else is on grex. Certainly not unbearable.
This response has been erased.
I type fast enough to have similar problems with richard when I type constantly, but usually I type a bit slower because my thoughts aren't all that gathered until I put them out. It's nice to be able to type fast enough to keep up with my thinking. I used to outrace grex enough that my old telnet program would lock me out and freeze. It was the original impetus for getting multiple logins.
This response has been erased.
why would running two editors at once hurt my .cf participation file?
Running two editors at once won't, unless you're editting your participation file. If you are editting your participation files by hand, then one editor is more than sufficient to damage the contents. I presume, though, that you mean running PicoSpan and Backtalk. PicoSpan reads your participation file when you enter a conference, and writes it out when you leave. If you run 2 copies of PicoSpan on the same conference, neither will know what the other has read, and when you leave the conference, the items that were marked seen for you will reflect whichever copy of PicoSpan last wrote the file out. If you were to leave the conference "at the same time" in both copies, then it is possible, although unlikely, that you could end up with a corrupted participation file (in practice, running out of disk space, or an I/O error, are more likely causes of a damaged file). When you use backtalk, the rules are different. I don't know exactly what Jan did, but most likely, most of the time, when you're reading stuff via the web, there is nothing at all running on grex. Only when you do something that causes your web browser to GET or POST a form on grex, is there any opportunity for backtalk to update your participation file. Most likely, therefore, backtalk updates your participation file *each time* you read a new item. So, if you had 2 copies of backtalk running at exactly the same time, it's possible (but unlikely) that they could trash your participation files. There are actually more ways for it to fail, because backtalk has to both read *and* write the file. So, bad things could happen if the second session is reading the file before the first session finishes writing it. If you ran both backtalk and picospan at the same time, but only did things with one at a time, then, most likely, PicoSpan will not "see" any changes made by backtalk while PicoSpan is in that conference, and when PicoSpan leaves that conference, any items marked "seen" only by backtalk, will revert to whatever state PicoSpan has remembered.
Which will look close enough to "trashed" from your perspective that it's better not to do it.
The main reason not to fo it is that neither will know what the other has seen. The result is that it is not updated properly. This is not really *corrupt*, but it is bad. Marcus is right that backtalk updates the participation file more often thatn picospan. Piocspan keeps its updated copy in core, and only writes it out when you switch conferences, exit, or explicitly request it. Picospan is thus more efficient with respect to file accesses, but is more prone to leaving the participation file out of date when there's a crash or other catastrophe.
(Actually, picospan writes my participation file at the end of every item for me, so backtalk and picospan would both be writing once an item.)
This response has been erased.
Backtalk does read and write the participation file each time you read an item. It holds a lock on the participation file between those two events, and I'm reasonably sure the locking is compatible with Picospan. I presume Picospan, like Yapp, only locks while reading or writing, not between. Thus, if you read with both at once, some of the things you read with Backtalk may show up unread again, but everything you read with Picospan should be OK, since Backtalk will not clobber Picospan's data. I've often used both to read at once (using "set autosave" in Picospan) and haven't had any big problems. It seems to work better than I would expect it to. I don't know why.
Oh, by the way, using Backtalk and Picospan simultaneously to read *different* conferences is 100% safe.
Which is they way I've always done it. It's very efficient use of time. Dunno, though, how efficient a use of Grexes resources it is, so I've stopped.
PicoSpan never locks participation files, and won't respect any file locks that might be present.
That makes things a bit scarier. I would thus advise not using Backtalk and Picospan on the same conference at the same time unless you don't care too much about your participation files getting trashed. The same goes for two Picospan invocations, but not for two Backtalk invocations.
Backtalk in anonymous mode would be perfectly safe. Run Picospan and as many anonymous Backtalks as you want.
This response has been erased.
You have several choices: