all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Re: non-blocking connect
       [not found]     ` <20041103133036.GK29018@boetes.org>
@ 2004-11-04  9:51       ` Richard Stallman
  2004-11-04 13:10         ` Jochem Kossen
  0 siblings, 1 reply; 10+ messages in thread
From: Richard Stallman @ 2004-11-04  9:51 UTC (permalink / raw)
  Cc: jkossen, emacs-devel

I see in that message two versions of a certain file, one good, one
corrupted.  (I forwarded the message here.)  How often does this
corruption occur?  Is it always at the same place, always identical?
If not, what varies?

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: non-blocking connect
  2004-11-04  9:51       ` non-blocking connect Richard Stallman
@ 2004-11-04 13:10         ` Jochem Kossen
  2004-11-04 15:21           ` Kai Grossjohann
                             ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Jochem Kossen @ 2004-11-04 13:10 UTC (permalink / raw)
  Cc: emacs-devel

On Thu, Nov 04, 2004 at 04:51:34AM -0500, Richard Stallman wrote:
> I see in that message two versions of a certain file, one good, one
> corrupted.  (I forwarded the message here.)  How often does this
> corruption occur?  Is it always at the same place, always identical?

It seems to corrupt the files around 3 of 10 times. It's not always at
the same place, and also not identical. So to sum up, everything is
pretty much random.

Now, i've set tramp-chunksize to 500 and 1024, and i can't seem to get
the corruption anymore :-S I'm now gradually trying higher values
(2048 atm). But i'm just trying this for about an hour, so don't
consider it a conclusion.

> If not, what varies?

The place of corruption in the file, and the 'characters'/binary data
it inserts.

So, the things i suspect might have something to do with it:
 - chunksize (what does the default do in comparison with values like
   500/1024/2048)? I read the documentation, but it doesn't mention
   what tramp does if it's set to nil.
 - traffic goes through an OpenBSD 3.6 firewall with scrubbing
   (traffic normalization) on

BTW, the remote/target host is running FreeBSD 5.2.1-RELEASE

Regards,

Jochem

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: non-blocking connect
  2004-11-04 13:10         ` Jochem Kossen
@ 2004-11-04 15:21           ` Kai Grossjohann
  2004-11-05  8:00           ` Stefan
  2004-11-05 15:01           ` Richard Stallman
  2 siblings, 0 replies; 10+ messages in thread
From: Kai Grossjohann @ 2004-11-04 15:21 UTC (permalink / raw)


Jochem Kossen <jkossen@xs4all.nl> writes:

> So, the things i suspect might have something to do with it:
>  - chunksize (what does the default do in comparison with values like
>    500/1024/2048)? I read the documentation, but it doesn't mention
>    what tramp does if it's set to nil.

Setting tramp-chunksize to 500 means that Tramp will send 500 bytes of
data, then wait a bit before sending the next chunk of data.

Setting tramp-chunksize to nil means that Tramp will send all of the
data at once, unchunked, so to speak.  (For instance, for writing a
file via base64 inline encoding, Tramp would base64-encode the buffer
contents, then send the whole encoded buffer to the remote end at once
with a single process-send-region invocation.)

Kai

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: non-blocking connect
  2004-11-04 13:10         ` Jochem Kossen
  2004-11-04 15:21           ` Kai Grossjohann
@ 2004-11-05  8:00           ` Stefan
  2004-11-08 15:45             ` Kai Grossjohann
  2004-11-05 15:01           ` Richard Stallman
  2 siblings, 1 reply; 10+ messages in thread
From: Stefan @ 2004-11-05  8:00 UTC (permalink / raw)
  Cc: Richard Stallman, emacs-devel

>> I see in that message two versions of a certain file, one good, one
>> corrupted.  (I forwarded the message here.)  How often does this
>> corruption occur?  Is it always at the same place, always identical?

> It seems to corrupt the files around 3 of 10 times. It's not always at
> the same place, and also not identical. So to sum up, everything is
> pretty much random.

What kind of corruption is it?
Could it just be due to the problem of SSH dropping some (multiple of
1024) bytes that we sometimes see in cunjunction with CVS?


        Stefan

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: non-blocking connect
  2004-11-04 13:10         ` Jochem Kossen
  2004-11-04 15:21           ` Kai Grossjohann
  2004-11-05  8:00           ` Stefan
@ 2004-11-05 15:01           ` Richard Stallman
  2 siblings, 0 replies; 10+ messages in thread
From: Richard Stallman @ 2004-11-05 15:01 UTC (permalink / raw)
  Cc: emacs-devel

You might be able to try debugging this by modifying various programs
used in the transmission, so that they compare the data being
transmitted against the correct contents of that file.  That way you
could at least determine where the corruption occurs.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: non-blocking connect
  2004-11-05  8:00           ` Stefan
@ 2004-11-08 15:45             ` Kai Grossjohann
  2004-11-08 17:06               ` Stefan Monnier
  0 siblings, 1 reply; 10+ messages in thread
From: Kai Grossjohann @ 2004-11-08 15:45 UTC (permalink / raw)


Stefan <monnier@iro.umontreal.ca> writes:

> What kind of corruption is it?
> Could it just be due to the problem of SSH dropping some (multiple of
> 1024) bytes that we sometimes see in cunjunction with CVS?

The documentation for the variable tramp-chunksize shows a method for
finding out if the bug is present in Emacs.  It seems to occur with
any program, not just wc and ssh.

Kai

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: non-blocking connect
  2004-11-08 15:45             ` Kai Grossjohann
@ 2004-11-08 17:06               ` Stefan Monnier
  2004-11-09 10:28                 ` Kai Grossjohann
  0 siblings, 1 reply; 10+ messages in thread
From: Stefan Monnier @ 2004-11-08 17:06 UTC (permalink / raw)
  Cc: emacs-devel

>> What kind of corruption is it?
>> Could it just be due to the problem of SSH dropping some (multiple of
>> 1024) bytes that we sometimes see in cunjunction with CVS?

> The documentation for the variable tramp-chunksize shows a method for
> finding out if the bug is present in Emacs.  It seems to occur with
> any program, not just wc and ssh.

Hmmm... so would it be a bug in Emacs?


        Stefan

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: non-blocking connect
  2004-11-08 17:06               ` Stefan Monnier
@ 2004-11-09 10:28                 ` Kai Grossjohann
  2004-11-09 14:13                   ` Stefan
  0 siblings, 1 reply; 10+ messages in thread
From: Kai Grossjohann @ 2004-11-09 10:28 UTC (permalink / raw)


Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> What kind of corruption is it?
>>> Could it just be due to the problem of SSH dropping some (multiple of
>>> 1024) bytes that we sometimes see in cunjunction with CVS?
>
>> The documentation for the variable tramp-chunksize shows a method for
>> finding out if the bug is present in Emacs.  It seems to occur with
>> any program, not just wc and ssh.
>
> Hmmm... so would it be a bug in Emacs?

Difficult to say: it seems to depend on a libc/Emacs interaction.

Kai

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: non-blocking connect
  2004-11-09 10:28                 ` Kai Grossjohann
@ 2004-11-09 14:13                   ` Stefan
  2004-11-10  7:52                     ` Kai Grossjohann
  0 siblings, 1 reply; 10+ messages in thread
From: Stefan @ 2004-11-09 14:13 UTC (permalink / raw)
  Cc: emacs-devel

> Difficult to say: it seems to depend on a libc/Emacs interaction.

Do you have a reasonably self-contained and easy way to (probablistically)
reproduce it?


        Stefan

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: non-blocking connect
  2004-11-09 14:13                   ` Stefan
@ 2004-11-10  7:52                     ` Kai Grossjohann
  0 siblings, 0 replies; 10+ messages in thread
From: Kai Grossjohann @ 2004-11-10  7:52 UTC (permalink / raw)
  Cc: Kai Grossjohann, emacs-devel

Stefan <monnier@iro.umontreal.ca> writes:

>> Difficult to say: it seems to depend on a libc/Emacs interaction.
>
> Do you have a reasonably self-contained and easy way to (probablistically)
> reproduce it?

Michael Albinus added code to the docstring of tramp-chunksize that
can be used to find out whether the problem is present in the current
Emacs/libc combination.  Is that good enough?

Kai

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2004-11-10  7:52 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20041101.133846.202527302.kazu@iijlab.net>
     [not found] ` <20041101050909.GR29502@boetes.org>
     [not found]   ` <E1COuPb-00014R-AB@fencepost.gnu.org>
     [not found]     ` <20041103133036.GK29018@boetes.org>
2004-11-04  9:51       ` non-blocking connect Richard Stallman
2004-11-04 13:10         ` Jochem Kossen
2004-11-04 15:21           ` Kai Grossjohann
2004-11-05  8:00           ` Stefan
2004-11-08 15:45             ` Kai Grossjohann
2004-11-08 17:06               ` Stefan Monnier
2004-11-09 10:28                 ` Kai Grossjohann
2004-11-09 14:13                   ` Stefan
2004-11-10  7:52                     ` Kai Grossjohann
2004-11-05 15:01           ` Richard Stallman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.