| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | USR Courier |
BG> How do you explain the vast majority of calls which actually BG> start out at the maximum link rate of either 28800 or 33600 then? RS> I'm not convinced that the 'vast majority' actually do. BG> I was talking about MY outbound connects, Dunno, I could have sworn you actually said the reverse in Aust_Modem but dont have any easy way to check that out. BG> and believe me when I tell you that 90% BG> of them connect at 28800/28800 straight up. Maybe. I am still dubious about claim at 33600 tho. Corse its possible split hairs and say that the vast bulk of your calls are to Dave and may possibly happen like that, but thats not really what we were talking about. BG> To me, that certainly is the absolute VAST majority. Not terribly relevant to the general question of what happens with the vast bulk of outgoing calls made by USR VEs by everyone tho. THATS whats relevant to the question we we actually discussing there, whether it tends to take the conservative route of a lower initial connect speed which then much more often INCREASES during the session than decreases. I'm damned sure that SOMEONE said that in Aust_Modems and I could have sworn it was you. BG> And no, I'm not complaining. :) Oh sure, thats clearly the desirable result. BG> In fact, on those calls which have started low, I used to BG> do an ATY11 line frequency response dump, and it was quite BG> obvious that the high end was marginal for full speed connects. RS> Yes, but thats a separate question to whether you would expect RS> the line conditions to generally IMPROVE during the call. You RS> would normally expect that it was just as like to move down as RS> up with a session which is marginal for full speed connects. BG> It may well do, but logged stats don't show this to be the case. Welp, someone said they did, and I could have sworn it was you. BG> One of V.34's greatest advantages is its ability to BG> speed-shift instantly and transparently (not at all BG> like the abortions that V.32bis retrains are), so there's BG> no way of knowing exactly what is happening during a call. Well, there is with a decent modem which displays those two speeds on the front of the modem during the call. And thats PRECISELY the value in that approach, you can see whats going on during the call. BG> Judicious use of the on-line ATY11 dump shows that line conditions BG> do vary quite considerably, even in the space of just a few seconds. Sure, no one disputes that they dont, the whole POINT of V34 is because they do and to keep wringing the best thruput out of the line as it changes. Completely separate issue to it having a considerable tendency to INCREASE during the session when you would in fact expect the change to be random. RS> Even sillier with a V32bis call, the modems negotiate a 14400 RS> connect fine, and then the damned USR virtually IMMEDIATELY demands RS> a retrain, on every single call I have made so far. Nuts IMO. BG> Have you called many (or any) other USR V.34s? What happens with those? RS> Should try I guess. Not too many that I can recall. BG> 07-3868-1597. That's David's Courier. Yeah, did yesterday, and I run a full international nodelist too. BG> Worth trying IMO. Yeah, just hadnt got around to looking very close, waiting for the weekend when its more convenient to do that. BG> Poe is closer, but he's had problems with his BG> lines since moving (possibly fixed now, dunno). Both produced IDENTICAL results, with about 5 calls to each. Both with the same mindless demand for a retrain straight after the connect and both with the same roughly 30% rate of falling flat on its face after that. Which conveniently eliminates any possibility of it being Pauls line, or a dud USR at his place, etc. BG> which could indicate that his lines are not 100% RS> Sure, but again, thats got SFA to do with demanding an immediate retrain RS> on a V32bis call which is nothing like as demanding as a V34+ call. BG> Of course, it couldn't be your Supra's ROM at fault, could it? :) Nope, not when its only seen when calling a USR VE, particularly when the line quality to get a V32bis 14400 session isnt exactly what you might call demanding. Its totally fucked behaviour by the USR VE. RS> Clearly its no surprise that you dont get full speed every RS> time with V34+, most people dont even if you do with Dave. BG> (not surprising in a block of units anyway). RS> I'm not convinced that units are relevant. It is after all RS> basically copper pairs back to the exchange, the fact that some RS> of its not in the ground isnt that likely to be that significant. BG> In units, the lines are all terminated in a large junction box, Yes, but there isnt any evidence that thats a particular problem given the use of those in pillars in the street etc. If anything those are less likely to be a problem given they are inside etc. BG> and given Paul's previous problems with TV antenna wiring, Thats got absolutely nothing to do with it, just because they used non UHF capable coax, says sweet fuck all about what Telecom has done with the phone wiring in that building. Almost certainly done by Telecom in the case of his building. I think this is more desperate clutching at straws to try to explain away the fact that the sun doesnt actually shine out of the USRs arse. Particularly when he does get a decent connect with the bulldog. BG> I wouldn't be at all surprised to find that somebody has BG> run the twisted pair alongside, for example, a mains wire, BG> which could easily induce 50Hz into the phone line. And the V34 standard is supposed to allow for that. It has to. BG> I have no faith at all in the builders' BG> ability to get it right in such edifices. Its not the builders that do it with phone wiring. --- PQWK202* Origin: afswlw rjfilepwq (3:711/934.2) SEEN-BY: 711/934 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.