| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 9484.1 | Not the way I'd want it work... | SSDEVO::ROLLOW | Dr. File System's Home for Wayward Inodes. | Mon Apr 14 1997 10:32 | 4 |
| Our implementation of /dev/null is such that we still have
have to read all the data, at least for things doing
sequential reads. Perhaps Sun "knows" that the output
file is a data-sink and doesn't bother reading the data.
|
| 9484.2 | | XIRTLU::schott | Eric R. Schott USG Product Management | Mon Apr 14 1997 11:11 | 7 |
| Hi
There could be something going on on the network...have you
run tcpdump to get a network trace during the operation each
way?
|
| 9484.3 | Is /dev/null really the null device? | VESPER::VESPER | OpenGL Alpha Geek | Mon Apr 14 1997 12:16 | 10 |
| >ftp> get file.dat /dev/null
>
>It tooks a long time, the same get from Alpha to Sun tooks no time.
Sometimes /dev/null gets trashed and replaced with a regular file.
Have your customer do "ls -l /dev/null" and make sure it is still
the null device.
Andy V
|
| 9484.4 | ``/dev/null implementation !? | NNTPD::"[email protected]" | Uri Lebovich | Tue Apr 15 1997 09:29 | 20 |
| .2
> There could be something going on on the network...have you
> run tcpdump to get a network trace during the operation each
> way?
The problem(s)/feature is't with network.
.3
> Have your customer do "ls -l /dev/null" and make sure it is still
> the null device.
Yes. Everithing is O.K.
Who can explain why "ftp> get file /dev/null" ( no I/O work ) tooks the same
time as "ftp> get file local_file" ???
Uri
[Posted by WWW Notes gateway]
|
| 9484.5 | | SSDEVO::ROLLOW | Dr. File System's Home for Wayward Inodes. | Tue Apr 15 1997 10:05 | 12 |
| So, just how much time is "no time" in your original note?
Impossibly fast? Or "making good use of available network
bandwidth"? If you wanted a program to appear faster in
certain common "benchmarks", a vendor might chose to take
the time to optimize certain output cases; such as writing
to /dev/null. As I said in my original reply, maybe Sun
doesn't bother to read the data when they know the output
file is the data-sink.
If they're just making better use of network bandwidth than
we are, more information about the test and configuration
would be useful.
|
| 9484.6 | check for earlier notes | TUXEDO::CHUBB | | Thu Apr 17 1997 12:02 | 9 |
| It seems I saw a discussion about /dev/null efficiency between us and
Sun in the past -- you may want to check with a 'dir/title=null' in
this conference and the old ALPHA_OSF conference.
It should be easy to get a rough idea with doing something like:
% cp /vmunix /dev/null
on both systems.
-- brandon
|
| 9484.7 | | NABETH::alan | Dr. File System's Home for Wayward Inodes. | Thu Apr 17 1997 13:23 | 6 |
| If Sun is taking short cuts, you might also try:
time cp /dev/zero /dev/null
If theirs finishes, they took a short cut. Ours won't
finish.
|
| 9484.8 | They must be doing something special... | RHETT::PARKER | | Thu Apr 17 1997 14:14 | 15 |
|
Good suggestion, Alan. I tried the copying /dev/zero to /dev/null
on SunOS 5.4 and it did not finish. But, they must be doing something
funny because I timed a copy of /kernel/unix to /dev/null and it took
no time.
time cp /kernel/unix /dev/null
0.0u 0.0s 0:00 0% 0+0k 0+0io 0pf+0w
If I can spare some cycles, I'll look into this more.
Hth,
Lee
|