Is 384 Kibit/s adequate for travel? [telecom]

We are going on a trip where the only communications options are satellite phone @$7/min or 384 Kibit/s internet @ 25-50 cents/min. How grim is this by today's standards?

Should we even try for email?

My router doesn't include an option to throttle the data rate, so that I could simulate what it will be like on the trip.

Reply to
Julian Thomas
Loading thread data ...

I've dealt with worse, throttled to 64kb when a mobile data package expired.

If your mail program does IMAP and you can tell it not to download attachments, it should be fine. You surely remember that mail was quite usable at 9600 bps.

R's, John

Reply to
John Levine

Grim? 384 Kbps is about par for my normal, home, "Hi-Speed" DSL link, on the download side. Upload is a tad slower. But at "25-50 cents/min" I'd be screaming "Highway Robbery!" Viewing video? Doing VoIP? Forget it. HTH.

Cheers, -- tlvp

Reply to
tlvp

By American standards it's pretty good. I wish I could get service that fast where I live. It's perfectly fine for email when people aren't sending enormous binary attachments, and it's just fine for ssh as well.

By European standards it's shamefully slow.

--scott

Reply to
Scott Dorsey

Just so.

I remember when it was considered advisable not to send email messages larger than 30K. Now many messages have more than 30K in the headers.

I use POP3 over dialup. Occasionally people send me multi-megabyte email - image collections among other things.

I have a script that opens a connection to the POP3 server, fetches a LIST and then headers for new messages (TOP n 0). It deletes spam and offers to delete large messages but allows me to see who they're from first and decline. This avoids the problem of, say, 10 meg of attachments to email from my friend (who should know better by now) vacationing in Burma blocking the one-liner I have to see before tearing off to the airport.

I always run the script before telling the mail client to fetch mail.

If your browser allows you to disable images and javascript, (how 20th century) that can also make a slow connection usable for the web. (Except, of course, cases where the images or js interactivity are essential to the purpose in hand.)

Reply to
Mike Spencer

Nope, IDSL was 144kbps. IDSL's main thing was to utilize both D's (64kbps each), and the B signal channel (16kbps) since you didn't need Q.921/Q.931 signalling over a dedicated IDSL.

So, 144kbps was a tiny incremental over the 128kbps a bonded ISDN dialup got you. Its main thing was that it was dedicated instead of dialup (even though the dialup setup on ISDN BRI was pretty fast), and probably didn't tie up two B channels on the voice switch, so the LECs liked it better, even if they had to roll different hardware. But it was symetric, and could be extended with ISDN type hardware.

But the routers for IDSL also sucked pretty hard. By the time IDSL rolled out, there was also SDSL at faster speeds. Higher price points, and required more direct paths, ala ADSL, but people would typically pick price and speed over the slightly wonkier and much slower IDSL.

Also, IDSL ran into many spectral interference issues when we were rolling out. It couldn't be in the same wire bundle as many other things. Much more repair and provisioning issues.

Reply to
Doug McIntyre

....

I was going to mention in my other post that OOTH, 384kbps is exactly 3 x ISDN BRI lines. This was quite a popular configuration for video conferencing, having 3 bonded BRI's together gave you just enough dedicated symmetric bandwidth for the video CODEC used without the variable analog modem changing speeds depending on line conditions.

I'd wager that there are still a few videoconferencing setups still out there using this as a solution rather than Internet bandwidth, although the cost is probably too high for most to justify keeping it.

Reply to
Doug McIntyre

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.