Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenSSH: Dev

scp: rounding bug in displayed transfer rate?

 

 

OpenSSH dev RSS feed   Index | Next | Previous | View Threaded


brolin at brolin

Mar 17, 2009, 10:43 PM

Post #1 of 20 (1800 views)
Permalink
scp: rounding bug in displayed transfer rate?

Hello,

[brolin [at] optiplex96] [0] [5] ~/
$ echo hello >hello.txt
...
[brolin [at] optiplex96] [1] [9] ~/
$ scp -pP 2222 hello.txt k7t266:~/
brolin [at] k7t26's password:
hello.txt
100% 6 0.0KB/s
00:00
[brolin [at] optiplex96] [0] [10] ~/
$

Why is the transfer rate "0.0KB/s"? That means nothing was
transferred. I think the transfer rate should be displayed in B/s
instead of KB/s if it is less than 0.1 KB/s because copying 6 bytes
but saying "0.0KB/s" is misleading and wrong to me.

Thanks,
Brolin

--
Sometimes I forget how to do small talk: <http://xkcd.com/222/>

"What if there were no hypothetical questions?" — George Carlin
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


peter at stuge

Mar 18, 2009, 4:34 AM

Post #2 of 20 (1756 views)
Permalink
Re: scp: rounding bug in displayed transfer rate? [In reply to]

Brolin Empey wrote:
> 100% 6 0.0KB/s 00:00
>
> Why is the transfer rate "0.0KB/s"?

Maybe it took less than one second, so no /s average is available?


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


brolin at brolin

Mar 18, 2009, 11:48 PM

Post #3 of 20 (1747 views)
Permalink
Re: scp: rounding bug in displayed transfer rate? [In reply to]

2009/3/18 Peter Stuge <peter [at] stuge>

> Brolin Empey wrote:
> > 100% 6 0.0KB/s 00:00
> >
> > Why is the transfer rate "0.0KB/s"?
>
> Maybe it took less than one second, so no /s average is available?
>

So what? After 1 second, it had still transferred 6 bytes.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


peter at stuge

Mar 19, 2009, 4:25 AM

Post #4 of 20 (1745 views)
Permalink
Re: scp: rounding bug in displayed transfer rate? [In reply to]

Brolin Empey wrote:
> > > Why is the transfer rate "0.0KB/s"?
> >
> > Maybe it took less than one second, so no /s average is available?
>
> So what? After 1 second, it had still transferred 6 bytes.

But the transfer didn't last one full second. Had it done so, the
actual transfer rate would quite likely be higher than 6b/s.

Are you suggesting that the program should wait idle until one full
second has passed from start of transfer - or that it should
fabricate a number which isn't accurate?

Sorry, but neither seems like an improvement to me.

It's simply impossible to calculate an average when there isn't an
excess of data. Here, the transfer rate resolution is one second.

Would you consider an "unmeasurable" style message to be an
improvement for cases when no transfer rate can be calculated?


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


brolin at brolin

Mar 20, 2009, 12:23 AM

Post #5 of 20 (1753 views)
Permalink
Re: scp: rounding bug in displayed transfer rate? [In reply to]

2009/3/19 Peter Stuge <peter [at] stuge>
>
> Brolin Empey wrote:
> > > > Why is the transfer rate "0.0KB/s"?
> > >
> > > Maybe it took less than one second, so no /s average is available?
> >
> > So what?  After 1 second, it had still transferred 6 bytes.
>
> But the transfer didn't last one full second. Had it done so, the
> actual transfer rate would quite likely be higher than 6b/s.

You mean 6 B/s. 6 b/s is less than 1 B/s. :P

Anyway, you are correct; I thought of that after I sent my message.

> Are you suggesting that the program should wait idle until one full
> second has passed from start of transfer - or that it should
> fabricate a number which isn't accurate?

As opposed to fabricating an accurate number? ;)

Seriously: no, I am not suggesting either of those changes.

> Sorry, but neither seems like an improvement to me.

I agree.

> It's simply impossible to calculate an average when there isn't an
> excess of data. Here, the transfer rate resolution is one second.

Then why does scp try to calculate an average when it has insufficient data?

> Would you consider an "unmeasurable" style message to be an
> improvement for cases when no transfer rate can be calculated?

No, I do not think scp should say anything in these cases because such
a message violates the Rule of Silence:
<http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2878450>

Incidentally, I think this discussion list should allow rich
(hyper)text mail so I can link parts of my prose instead of pasting
URLs: in the case of the previous paragraph, the pasted URL is almost
as long as the sentence on the previous line — even when using a
proportional font. Why am I limited to plain text when using a
computer to write about computer software?

Perhaps I am too contemporary for this discussion list: I am writing
this message in a proportional font in Gmail's Web interface in
Mozilla Firefox on Windows Vista with subpixel font antialiasing on a
widescreen LCD monitor. ;)
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


gert at greenie

Mar 20, 2009, 1:55 AM

Post #6 of 20 (1747 views)
Permalink
Re: scp: rounding bug in displayed transfer rate? [In reply to]

Hi,

On Fri, Mar 20, 2009 at 12:23:33AM -0700, Brolin Empey wrote:
> Perhaps I am too contemporary for this discussion list: I am writing
> this message in a proportional font in Gmail's Web interface in
> Mozilla Firefox on Windows Vista with subpixel font antialiasing on a
> widescreen LCD monitor. ;)

You are. We are interested in content, not in presentation.

I'm reading this in an 80x24 xterm using "mutt", because it's WAY faster
to use the keyboard than having klick on things all the time.

gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert [at] greenie
fax: +49-89-35655025 gert [at] net
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


bob at proulx

Mar 20, 2009, 9:55 AM

Post #7 of 20 (1742 views)
Permalink
Re: scp: rounding bug in displayed transfer rate? [In reply to]

Brolin Empey wrote:
> Incidentally, I think this discussion list should allow rich
> (hyper)text mail so I can link parts of my prose instead of pasting
> URLs:

Please no.

> in the case of the previous paragraph, the pasted URL is almost
> as long as the sentence on the previous line — even when using a
> proportional font.

Is that important? It doesn't seem to matter.

> Why am I limited to plain text when using a computer to write about
> computer software?

More value is place on function over form.

Plain text email is viewed using the recipient's preferred fonts and
colors, which enhances accessibility. HTML email is viewed using the
sender's preferred fonts and colors, which often make reading the
message harder for the recipient. Senders cannot know what the best
form is for the recipient.

> Perhaps I am too contemporary for this discussion list: I am writing
> this message in a proportional font in Gmail's Web interface in
> Mozilla Firefox on Windows Vista with subpixel font antialiasing on a
> widescreen LCD monitor. ;)

I am happy that you have cool toys to play with but Email is written
to be read by others. If others find it harder to read then it isn't
accomplishing a good result.

Bob
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


peter at stuge

Mar 20, 2009, 10:24 AM

Post #8 of 20 (1741 views)
Permalink
Re: scp: rounding bug in displayed transfer rate? [In reply to]

Brolin Empey wrote:
> > But the transfer didn't last one full second. Had it done so, the
> > actual transfer rate would quite likely be higher than 6b/s.
>
> You mean 6 B/s. 6 b/s is less than 1 B/s. :P

Personally I make no difference between b and B. Conventions differ
almost on a personal basis so I just keep it simple with lowercase
all the time. For bits per second my preference is to use bps. I
guess a habit from the modem days..


> > It's simply impossible to calculate an average when there isn't an
> > excess of data. Here, the transfer rate resolution is one second.
>
> Then why does scp try to calculate an average when it has
> insufficient data?

I think there are two reasons for this;

1. It is a corner case where accuracy does not make a big difference.
Being a corner case means that some amount of code needs to go
into OpenSSH to cover it, but that code would not run very often.
That's bad from a security/code quality perspective. The fact that
the inaccuracy is near unmeasurable further motivates ignoring the
problem.

2. Noone has felt strongly about making this more accurate.

I do not know which is the stronger motivator, but I think both are
important reasons.


> > Would you consider an "unmeasurable" style message to be an
> > improvement for cases when no transfer rate can be calculated?
>
> No, I do not think scp should say anything in these cases because
> such a message violates the Rule of Silence:

Hm. A little problematic because the other fields still have valid
information. Omitting the throughput field would introduce a rather
messy inconsistency in the program's output.

If I were to interpret scp output programmatically I would be able to
deal with 0 much more easily than <no value specified> especially
since I may be using whitespace as field separator.


> <http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2878450>
>
> Incidentally, I think this discussion list should allow rich
> (hyper)text mail so I can link parts of my prose instead of pasting
> URLs:

In this case I'd suggest to simply quote the rule (just the rule
though) and save people who read your message a web dereference.


It's quite interesting how two totally f*ed up technologies (web and
email) can combine into something that people live their lives by.

Webmail: Two wrongs don't make a right!


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


brolin at brolin

Mar 20, 2009, 4:31 PM

Post #9 of 20 (1741 views)
Permalink
Re: scp: rounding bug in displayed transfer rate? [In reply to]

2009/3/20 Gert Doering <gert [at] greenie>
>
> Hi,
>
> On Fri, Mar 20, 2009 at 12:23:33AM -0700, Brolin Empey wrote:
> > Perhaps I am too contemporary for this discussion list:  I am writing
> > this message in a proportional font in Gmail's Web interface in
> > Mozilla Firefox on Windows Vista with subpixel font antialiasing on a
> > widescreen LCD monitor. ;)
>
> You are.  We are interested in content, not in presentation.

I was joking, hence the ";)". I am interested in content too, but I
like to use links in e-mail without having to paste long URLs. I also
like to be able to use rich text formatting such as bold, italic, and
monospaced (as opposed to proportional) text for emphasis. I am used
to using such formatting in e-mail and on Web forums. I wrote the
paragraph you quoted because I thought limiting discussion list users
to plain text seems to support the stereotype that discussion lists
and Usenet are for people who are so passionate about criticising HTML
e-mail that they include such things as "ASCII ribbon against HTML
e-mail" in their signatures. I like to use Unicode characters, such
as em dashes, arrows, copyright, registered, and trade mark symbols
instead of ASCII approximations. That is why I joked that I was too
contemporary for this discussion list. Artificial limitations seem
silly because I am using a GUI on a microcomputer, not a text terminal
connected to a mainframe or minicomputer. However, I have still
respected the rules of this discussion list by using plain text. Of
course, I know text terminals are not limited to use with mainframes
and minicomputers. I frequently use terminal emulators, console
windows (on Windows), and text-mode or (graphics-mode) frame buffer
VTs on Linux. I have even written Linux man pages. I used to be
convinced by plain text supporters that e-mail should be written in
plain text, but I switched to HTML e-mail because I like the
presentational control offered by rich text. I still believe in
separation of structure from presentation, which is why I prefer using
document markup languages, such as XHTML + CSS, in a text editor over
graphical word processors. I have seen many users of graphical word
processors hard-wire text formatting instead of using classes or
styles. Granted, I suppose I may be hard-wiring formatting in HTML
e-mail, but it does not bother me because no one has ever complained
nor have I been unable to read HTML e-mail from others. I could
probably use user stylesheets if I really wanted all of my received
e-mail to be presented uniformly, but I am not sufficiently motivated
to do so.

> I'm reading this in an 80x24 xterm using "mutt", because it's WAY faster
> to use the keyboard than having klick on things all the time.

I am not clicking all the time while using a WIMP/GUI environment to
read and write e-mail; I am not one of those users who uses the mouse
to select the next field in a form instead of pressing Tab. :P

I agree about the keyboard being faster than the mouse (or other
pointing device) for certain tasks. For example, I use many readline
shortcuts in bash. I also prefer to use the keyboard exclusively to
edit text with Vim.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


Jefferson.Ogata at noaa

Mar 20, 2009, 6:21 PM

Post #10 of 20 (1743 views)
Permalink
Re: scp: rounding bug in displayed transfer rate? [In reply to]

On 2009-03-20 23:31, Brolin Empey wrote:
> I was joking, hence the ";)". I am interested in content too, but I
> like to use links in e-mail without having to paste long URLs. I also

http://tinyurl.com/

> like to be able to use rich text formatting such as bold, italic, and
> monospaced (as opposed to proportional) text for emphasis. I am used
> to using such formatting in e-mail and on Web forums. I wrote the
> paragraph you quoted because I thought limiting discussion list users
> to plain text seems to support the stereotype that discussion lists
> and Usenet are for people who are so passionate about criticising HTML
> e-mail that they include such things as "ASCII ribbon against HTML
> e-mail" in their signatures. I like to use Unicode characters, such
> as em dashes, arrows, copyright, registered, and trade mark symbols
> instead of ASCII approximations. That is why I joked that I was too

I don't know about this list, but there's no reason that you can't use
Unicode in plain text documents, with UTF-8 encoding.

Unicï½ï½„ï½… test

--
Jefferson Ogata <Jefferson.Ogata [at] noaa>
NOAA Computer Incident Response Team (N-CIRT) <ncirt [at] noaa>
"Never try to retrieve anything from a bear."--National Park Service
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


brolin at brolin

Mar 21, 2009, 5:25 AM

Post #11 of 20 (1740 views)
Permalink
Re: scp: rounding bug in displayed transfer rate? [In reply to]

2009/3/20 Jefferson Ogata <Jefferson.Ogata [at] noaa>:
> On 2009-03-20 23:31, Brolin Empey wrote:
>> I was joking, hence the ";)". I am interested in content too, but I
>> like to use links in e-mail without having to paste long URLs. I also
>
> http://tinyurl.com/

You missed my point: I meant I like to be able to link parts of my
prose instead of pasting URLs of /any/ length. Oh well, it is not a
big deal.
>
>> like to be able to use rich text formatting such as bold, italic, and
>> monospaced (as opposed to proportional) text for emphasis. I am used
>> to using such formatting in e-mail and on Web forums. I wrote the
>> paragraph you quoted because I thought limiting discussion list users
>> to plain text seems to support the stereotype that discussion lists
>> and Usenet are for people who are so passionate about criticising HTML
>> e-mail that they include such things as "ASCII ribbon against HTML
>> e-mail" in their signatures. I like to use Unicode characters, such
>> as em dashes, arrows, copyright, registered, and trade mark symbols
>> instead of ASCII approximations. That is why I joked that I was too
>
> I don't know about this list, but there's no reason that you can't use
> Unicode in plain text documents, with UTF-8 encoding.

Yes, I know.

> $B#U#n#i#c#o#d#e(B $B#t#e#s#t(B

Your test appears to have succeeded because I can read "Unicode test".


brolin at brolin

Mar 21, 2009, 5:57 AM

Post #12 of 20 (1736 views)
Permalink
Re: scp: rounding bug in displayed transfer rate? [In reply to]

2009/3/20 Bob Proulx <bob [at] proulx>:
> Brolin Empey wrote:
>> in the case of the previous paragraph, the pasted URL is almost
>> as long as the sentence on the previous line — even when using a
>> proportional font.
>
> Is that important?  It doesn't seem to matter.

My point was that only one line instead of two is required if I can
link part of my sentence instead of having to paste the URL.

>> Why am I limited to plain text when using a computer to write about
>> computer software?
>
> More value is place on function over form.
>
> Plain text email is viewed using the recipient's preferred fonts and
> colors, which enhances accessibility.  HTML email is viewed using the
> sender's preferred fonts and colors, which often make reading the
> message harder for the recipient.  Senders cannot know what the best
> form is for the recipient.

This is probably true in some circumstances, but I do not think it
affects any of the people with whom I correspond via e-mail.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


bob at proulx

Mar 21, 2009, 10:27 AM

Post #13 of 20 (1731 views)
Permalink
Re: scp: rounding bug in displayed transfer rate? [In reply to]

Brolin Empey wrote:
> Bob Proulx wrote:
> > Plain text email is viewed using the recipient's preferred fonts and
> > colors, which enhances accessibility. HTML email is viewed using the
> > sender's preferred fonts and colors, which often make reading the
> > message harder for the recipient. Senders cannot know what the best
> > form is for the recipient.
>
> This is probably true in some circumstances, but I do not think it
> affects any of the people with whom I correspond via e-mail.

You just now corresponded via e-mail with myself and with hundreds of
other members of the mailing list.

Bob
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


brolin at brolin

Mar 21, 2009, 2:17 PM

Post #14 of 20 (1727 views)
Permalink
Re: scp: rounding bug in displayed transfer rate? [In reply to]

2009/3/21 Bob Proulx <bob [at] proulx>:
> Brolin Empey wrote:
>> Bob Proulx wrote:
>> > Plain text email is viewed using the recipient's preferred fonts and
>> > colors, which enhances accessibility.  HTML email is viewed using the
>> > sender's preferred fonts and colors, which often make reading the
>> > message harder for the recipient.  Senders cannot know what the best
>> > form is for the recipient.
>>
>> This is probably true in some circumstances, but I do not think it
>> affects any of the people with whom I correspond via e-mail.
>
> You just now corresponded via e-mail with myself and with hundreds of
> other members of the mailing list.

I was not sufficiently precise: I meant I do not think any of the
people to whom I send HTML e-mail are affected by the accessibility
issues of HTML e-mail. I have sent only plain-text e-mail to this
list.

Anyway, I apologise for sidetracking this discussion. I will now
attempt to get back on track.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


brolin at brolin

Mar 21, 2009, 5:19 PM

Post #15 of 20 (1729 views)
Permalink
Re: scp: rounding bug in displayed transfer rate? [In reply to]

2009/3/20 Peter Stuge <peter [at] stuge>:
> Brolin Empey wrote:
>> > But the transfer didn't last one full second. Had it done so, the
>> > actual transfer rate would quite likely be higher than 6b/s.
>>
>> You mean 6 B/s.  6 b/s is less than 1 B/s. :P
>
> Personally I make no difference between b and B. Conventions differ
> almost on a personal basis so I just keep it simple with lowercase
> all the time. For bits per second my preference is to use bps. I
> guess a habit from the modem days..

The formal convention is to use 'B' for bytes and 'b' for bits.
However, many people mistakenly use 'b' for bytes. I can usually
still tell what they mean because a combination such as "mb" for
megabytes really means millibits, which is impossible because a bit is
a fundamental unit of information.

I am a purist. Incorrect common usage bothers me even if I know what is meant.

>> > Would you consider an "unmeasurable" style message to be an
>> > improvement for cases when no transfer rate can be calculated?
>>
>> No, I do not think scp should say anything in these cases because
>> such a message violates the Rule of Silence:
>
> Hm. A little problematic because the other fields still have valid
> information. Omitting the throughput field would introduce a rather
> messy inconsistency in the program's output.

Yes, I realise this. The throughput field could be moved so it is the
last field on the line, but that would break compatibility with
scripts that expect the throughput field to be the second-last field.

The throughput field could also be interpreted as a boolean expression
in C: the field's value is false if it is zero. :)

> If I were to interpret scp output programmatically I would be able to
> deal with 0 much more easily than <no value specified> especially
> since I may be using whitespace as field separator.

I realise this too. How about printing "-.-KB/s" instead of
"0.0KB/s"? The '-'s mean no value is specified, but the presence of
the decimal point and rate indicate that a value would be specified
under non-exceptional conditions.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


mouring at eviladmin

Mar 21, 2009, 6:45 PM

Post #16 of 20 (1734 views)
Permalink
Re: scp: rounding bug in displayed transfer rate? [In reply to]

On Mar 21, 2009, at 7:19 PM, Brolin Empey wrote:
[..]
>> If I were to interpret scp output programmatically I would be able to
>> deal with 0 much more easily than <no value specified> especially
>> since I may be using whitespace as field separator.
>
> I realise this too. How about printing "-.-KB/s" instead of
> "0.0KB/s"? The '-'s mean no value is specified, but the presence of
> the decimal point and rate indicate that a value would be specified
> under non-exceptional conditions.

If you feel this should be done then please write a patch and submit
it to the bugzilla tracking page. Most around here don't feel it is
detrimental nor worth investing development cycles.

- Ben
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


Jefferson.Ogata at noaa

Mar 22, 2009, 1:42 AM

Post #17 of 20 (1720 views)
Permalink
Re: scp: rounding bug in displayed transfer rate? [In reply to]

On 2009-03-22 00:19, Brolin Empey wrote:
> The formal convention is to use 'B' for bytes and 'b' for bits.
> However, many people mistakenly use 'b' for bytes. I can usually
> still tell what they mean because a combination such as "mb" for
> megabytes really means millibits, which is impossible because a bit is
> a fundamental unit of information.

A millibit is a valid measure of entropy. Otherwise you are correct.

--
Jefferson Ogata <Jefferson.Ogata [at] noaa>
NOAA Computer Incident Response Team (N-CIRT) <ncirt [at] noaa>
"Never try to retrieve anything from a bear."--National Park Service
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


brolin at brolin

Mar 22, 2009, 2:49 AM

Post #18 of 20 (1712 views)
Permalink
Re: scp: rounding bug in displayed transfer rate? [In reply to]

2009/3/22 Jefferson Ogata <Jefferson.Ogata [at] noaa>:
> A millibit is a valid measure of entropy. Otherwise you are correct.

Which sense of entropy do you mean?

<http://dictionary.reference.com/browse/entropy>

I assume you mean:

2. (in data transmission and information theory) a measure of the
loss of information in a transmitted signal or message.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


Jefferson.Ogata at noaa

Mar 22, 2009, 8:23 AM

Post #19 of 20 (1705 views)
Permalink
Re: scp: rounding bug in displayed transfer rate? [In reply to]

On 2009-03-22 09:49, Brolin Empey wrote:
> 2009/3/22 Jefferson Ogata <Jefferson.Ogata [at] noaa>:
>> A millibit is a valid measure of entropy. Otherwise you are correct.
> I assume you mean:
>
> 2. (in data transmission and information theory) a measure of the
> loss of information in a transmitted signal or message.

Yes, Shannon's entropy.

http://en.wikipedia.org/wiki/Entropy_(Information_theory)

--
Jefferson Ogata <Jefferson.Ogata [at] noaa>
NOAA Computer Incident Response Team (N-CIRT) <ncirt [at] noaa>
"Never try to retrieve anything from a bear."--National Park Service
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


dkg at fifthhorseman

Mar 23, 2009, 12:45 PM

Post #20 of 20 (1676 views)
Permalink
Re: scp: rounding bug in displayed transfer rate? [In reply to]

On 03/21/2009 05:17 PM, Brolin Empey wrote:
> Anyway, I apologise for sidetracking this discussion. I will now
> attempt to get back on track.

So, speaking of "scp: rounding bug in displayed transfer rate"...

Other tools appear to deal with this same problem in a different way:

http://blog.rupamsunyata.org/2009/03/23/artificial-intelligence.xhtml

our machines are clearly capable of measuring timestamps with finer
granularity than 1 second, even if they report human-comprehensible
times to the (presumably human) user.

I wouldn't see a reason reject a patch that allowed scp to produce
output of "42B/s" if 1 byte gets transferred in 1/42 seconds.

--dkg
Attachments: signature.asc (0.87 KB)

OpenSSH dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.