|
|
| Author |
Message |
| 25 new of 283 responses total. |
davel
|
|
response 200 of 283:
| 
Feb 15 12:10 UTC 1999 |
You'd be surprised at how many people are still out there with slower modems,
I think. (Not including me, at the moment, but that's new as of early
December ... and I'm having trouble with the new modem.)
|
davel
|
|
response 201 of 283:
|
Feb 15 12:11 UTC 1999 |
(Scott slipped in.)
|
flem
|
|
response 202 of 283:
|
Feb 15 15:51 UTC 1999 |
As I understand it, error correcting codes (most of them, anyway) work
under the assumption that errors are relatively rare. Also, stronger
error correction slows down transmission. I imagine that most modems
that are "error correcting" don't use very sophisticated correction
algorithms, so as to maximize speed.
|
jazz
|
|
response 203 of 283:
|
Feb 15 16:09 UTC 1999 |
You're right, error correction does slow down transmission - frames
have to be retransmitted when they don't go through correctly, even if they
are very small frames. Software error correction is very flexible about this
- you could choose xmodem for a noisy line or zmodem with large sliding
windows for a clean line - but hardware isn't so flexible.
|
keesan
|
|
response 204 of 283:
|
Feb 15 22:42 UTC 1999 |
I could not get xmodem to work with grex, only Kermit and ymodem. Used to
get a lot of garbage on the line before switching modems.
|
flem
|
|
response 205 of 283:
|
Feb 16 03:40 UTC 1999 |
Does "error correcting" hardware actually correct errors if they are
detected, or does it merely detect them and require retransmission, like
tcp/ip? My roommate, a networking type, seems to think that most modem
protocols just do error detection.
|
scg
|
|
response 206 of 283:
|
Feb 16 04:33 UTC 1999 |
They detect and then retransmit. Since the data with errors is by definition
corrupted, there's no good way for the modem on the receiving end to know
what's supposed to be there once it fails its checksum.
|
mcnally
|
|
response 207 of 283:
|
Feb 16 06:43 UTC 1999 |
re #206: given enough redundancy, bit errors can be correctable
(many minicomputer memories were able to repair single
bit errors, more advanced correction schemes were less
common.) but your response to #205 is otherwise correct,
the modems do error detection/retransmission, not true
error correction.
|
flem
|
|
response 208 of 283:
|
Feb 16 15:51 UTC 1999 |
I recently was exposed to the mathematics behind some simple error
correcting codes, and I was fascinated. But they probably wouldn't be
commercially viable for modems.
|
dpc
|
|
response 209 of 283:
|
Feb 16 16:44 UTC 1999 |
I have a mail-reading problem. Sitting *unread* in the System's
innards are 12 pieces of e-mail, some of which have *gasp!* MIME
attachments. If I type !mail, as is my wont, the attachments
come out as garbage.
I *think* pine supports attachments, but I've never used
it. What command(s) should I use to read the first piece of e-mail,
including its attachment? What command(s) should I use to read
the next piece of e-mail, including its attachment?
Remember--these e-mails are *not* in my mbox, but are still
unread.
Thanx!
|
mcnally
|
|
response 210 of 283:
|
Feb 16 17:57 UTC 1999 |
Pine will indeed handle MIME attachments.
The only thing you really need to watch out for when running it for
the first time is that recent versions of Pine seem to like to take
your mail out of the system mailbox in /var/spool/mail/$USER and
copy it to your home directory. If you routinely leave mail in your
system inbox rather than sorting it into folders or putting it in
mbox after it's read then you may wonder where your incoming mail
has gone.
Otherwise you can just type "pine" to start the program, and from the
main menu choose "i" to go to the "message index". Use the arrow keys
to highlight the piece of mail you want to read and press return.
Pine will tell you it's a multi-part message and should go into a special
mode where you can choose to view or save the various attachments.
|
remmers
|
|
response 211 of 283:
|
Feb 16 18:23 UTC 1999 |
Dunno if this applies to dpc's mail, but many kinds of attachments
require that an external program be run to read them; pine doesn't
have the capability built-in. And if an appropriate program isn't
available on Grex...
It would be kind of difficult to read an MS Word document on Grex,
for example, or play a MIDI file.
But at least pine should let you save an attachment in a file, for
later download.
|
dpc
|
|
response 212 of 283:
|
Feb 16 19:10 UTC 1999 |
It worked!! Mostly. And pine didn't even swipe the mail from
the System's file, although it did build something in my home
directory--and it told me so.
I was able to read the first attachment, and I assume I'll
be able to read the attachments in the other e-mails. There is
just one problem: If the attachment is more than one page, it
doesn't "scroll up." Instead, when I press a space for the next
page, that next page *overwrites* the previous page.
What do I have to tell pine to get it to scroll messages up
so that I can print them all in one piece from my buffer?
|
gull
|
|
response 213 of 283:
|
Feb 16 19:58 UTC 1999 |
Good question -- the easiest way would be to save the message to your home
directory (with 'E'xport or 'S'ave, depending on whether it's a normal mail
message or an attachment) and deal with it from there. You can use the
'cat' command to list a file in your home directory. Pine also has a
pr'Y'nt command, which attempts to send a control code to your terminal
program to tell it to turn on the printer. This works with a few terminal
programs, but many don't support it anymore.
|
dpc
|
|
response 214 of 283:
|
Feb 16 21:22 UTC 1999 |
Hm. Well, I was hoping that there was a command like that in "lynx",
where you can type "enable_scrollback" and the web documents scroll up
instead of disappearing. Isn't this possible with pine? I'd rather
not have to go through the rigmarole of saving a document to my directory,
then doing "cat <filename>" and then printing...
|
scg
|
|
response 215 of 283:
|
Feb 16 23:40 UTC 1999 |
re 207:
Yes, but that much redundancy would consume bandwidth, thus also
slowing modems down.
|
russ
|
|
response 216 of 283:
|
Feb 17 05:17 UTC 1999 |
Re #207 et al: Error-correcting codes are commonly used where
retransmission is impractical, e.g. broadcast systems. I have
seen them used in both military and civilian radio gear. The
technique is generally called "forward error correction" (FEC),
and there are quite a few different schemes available in
"cook-book" form if you decide to write one.
|
dang
|
|
response 217 of 283:
|
Feb 17 06:20 UTC 1999 |
Hense packet radio being so terminally slow. :)
|
jshafer
|
|
response 218 of 283:
|
Feb 17 08:01 UTC 1999 |
Is it just me, or is the queue much longer than 'normal'?
|
gull
|
|
response 219 of 283:
|
Feb 17 19:29 UTC 1999 |
Re #217: Packet radio, at least the amateur variety, uses a retransmission
scheme, not an error-correction one.
|
krj
|
|
response 220 of 283:
|
Feb 17 19:42 UTC 1999 |
Network connections have been very laggy for the last two days, in
the afternoon. pfv and I, who were both connecting through
michnet, were seeing connection hangs of 20-30 seconds yesterday,
and pete was measuring 40% packet loss. This might not be
Grex's problem, but other people in party were making similar
observations yesterday, and I was not experiencing problems with
connections to m-net or msen.
|
pthomas
|
|
response 221 of 283:
|
Feb 17 23:21 UTC 1999 |
Same problem with the dialins. Currently, load averages are above 17. This
could possibly be a cause.
|
davel
|
|
response 222 of 283:
|
Feb 18 01:35 UTC 1999 |
uptime
8:34pm up 6 days, 6:05, 69 users, load average: 2.95, 2.81, 2.93
And the system seems quite reasonably fast.
|
steve
|
|
response 223 of 283:
|
Feb 18 04:47 UTC 1999 |
There have been a multitide of problems lately. None of them
are Grex's fault I think, but they do affect us.
First, we've gotten hit by some strange web requests all at
once, such that we had many apache processes running at once,
hogging things.
Second, we've had some "interesting" network problems--I was
going half mad today, trying to do useful things while at MSU
and got hung up on many times.
Third, there was a truely obnoxious and bizarre problem with
an email site that sent an absolute birrage of email to us for
one unsubscribed user, and that brought the system down. Oh,
this was yesteray so at least we didn't have three seperate
strange things happening in one day. ;-)
|
jshafer
|
|
response 224 of 283:
|
Feb 18 10:33 UTC 1999 |
Hmm. /a seems to be full. My agora participation file
got munched, but that's no big deal... (I did send mail
to staff, in case they weren't aware of the situation.)
|
