| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1414.1 | Need more info | SCHOOL::WASHABAUGH | Born to be Mild | Thu Aug 04 1994 16:31 | 16 |
| - What test tool was being used to generate the traffic?
- How was the throughput measured?
- Was the data going to/from disk?
- How do you know that you are using 4K packets? A network monitor is the only
sure way.
I have not done any DECnet performance. The testing that I do between a Jensen
and a 450ST running netbui. Between the two machines, I get 40 Mbits/sec, low
CPU util (30%). We have seen higher using better CPUs. The test tool was
PFTEST, which basically copies files. The OS was Windows NT 3.1.
Can you try repeating the test, using DECNET, TCP/IP and NETBUI? I would
like to know how the performance varies among the protocols. What is the
Ethernet performance in that configuration?
Doug, author of the DEFEA Windows NT driver, but no longer its maintainer...
|
| 1414.2 | | koning.lkg.dec.com::koning | Paul Koning, B-16504 | Fri Aug 05 1994 13:02 | 22 |
| There is very little INHERENT difference in overhead among protocols
(with the possible exception of IBM-designed ones). There is, however,
enormous variation in implementation quality.
For instance, the first tests of IP over FDDI on Alpha produced about
15 Mb/s throughput, barely better than Ethernet. This was obviously
unacceptable, and a team went to work to fix it. Within weeks, performance
had doubled or tripled, and when they were finished, the system ran at
wire speed with CPU to spare.
Sometimes there are simple bug that make performance suck. Sometimes the
problems are more intricate than that. But no, there is no valid excuse
for DECnet performance -- under comparable tests -- to be significantly
worse than that of any other protocol.
Be sure, however, that you are doing a valid test. If you're comparing
a high overhead application with a low overhead one, you're measuring
the application, not the underlying network connection. If you're measuring
file transfer performance, you may be testing disk speed rather than
network speed. And so on...
paul
|
| 1414.3 | New tests, better performance | VNABRW::BECK_R | | Fri Aug 12 1994 05:41 | 10 |
| our (small) test program does decnet task-to-task communication.
the first version (throughput in .0) used PWSOCKETS, and we also
had a packetsize problem (decnet wouldn't send packets > ~5k).
by using WINSOCKETS we got ~2,4 MByte/s on Pentium receiver which is
still cpu-bound, but we solved the packetsize problem.
anyway, customer is now waiting for daytona, PW and FDDI-PCI boards.
we also will test IP throughput with the current config.
regards roland
|
| 1414.4 | | 4371::STEFANI | Have the # for the Mars Observer? | Fri Aug 12 1994 08:52 | 16 |
| >>our (small) test program does decnet task-to-task communication.
>>the first version (throughput in .0) used PWSOCKETS, and we also
>>had a packetsize problem (decnet wouldn't send packets > ~5k).
Did you mean packet or record size bigger than ~5K? As an FYI, the
maximum size FDDI LLC packet excluding the CRC is 4491 bytes, so a 5K
sized packet (or bigger) would be illegal.
>>anyway, customer is now waiting for daytona, PW and FDDI-PCI boards.
>>we also will test IP throughput with the current config.
I took over the NT drivers for the DEFEA and DEFPA (PCI) controllers,
and have started adding the changes to support PCI. It should be
available by the time the DEFPA ships.
- Larry
|
| 1414.5 | 10 clients take 100% CPU on AXP 2100. | LURE::CERLING | 18,446,744,073,709,551,615 | Fri Sep 16 1994 13:10 | 33 |
|
I am experiencing a similar performance problem.
AXP2100, single processor
128 MB memory
RAID5 (though all files are cached during test)
DEFEA
Netbeui
Windows NT 3.5 (beta 2 and RC2)
Clients are DEC 590s with 16 MB memory and Intel Pro cards running
Windows for Workgroups.
The 2100 is working as a file server to serve video clips. For the
test we have been using a 6.6 MB file that runs for about 45
seconds. I see the following trend as I add each client.
1 2 3 4 5 6 7 8 9 10 11
CPU% 13 23 34 45 54 64 74 83 92 98 99
Net MBs .3 .6 .9 1.2 1.5 1.8 2.1 2.4 2.7 2.85 2.85
It is nice and linear, but as you can see, it eats up the CPU
way too fast. We need to be able to run 18-24 PCs off this
system. Any ideas as to why working as a file server for
this application takes soooo much CPU? Any ideas on how to
get this better?
Any help would be appreciated. I am pursuing this through
other channels as well, but was hoping the network experts would
have some more insight. At risk - 200 2100 servers.
tim cerling
software consultant
|
| 1414.6 | | 56821::STEFANI | Have the # for the Mars Observer? | Mon Sep 19 1994 10:00 | 34 |
| re: -.1
Tim,
I tried contacting you over the phone, but couldn't reach you. I
assume you're running the current IFT DEFEA-NT drivers from Vince on
Windows NT 3.5 Release Candidate 1 or better. Do NOT use the drivers
with BETA 2 or earlier since there were some NDIS wrapper bugs that
prevented the driver from operating properly. They've since been
fixed.
With regards to your application, I don't know why you're seeing the
behavior that you are. The driver and DEFEA probably use the least
amount of CPU utilization compared to most Bus Master cards given that
we perform DMA directly from the transmit buffer fragments, without any
intermediate buffer copy. On the receive-side, we DMA into our own
pool of buffers, then perform a buffer copy during receive indications,
as per the NDIS 3.0 specification. All in all, the driver/adapter
should be very efficient when it comes to CPU utilization.
I think your best bet is to pull someone from Microsoft technical
support onto this. Someone who could explain the loading factor on
NetBEUI as you increase the number of users. If they have
recommendations on what the driver can do, I'll be more than happy to
listen. By the way, there is a limited amount of tuning that you can
do to the driver. For example, you can increase the number of receive
buffers in the driver's local pool and increase the number of map
registers (transmit buffers) allocated by the driver. Both of these
parameters may (emphasize "may") have an impact on the performance of
your application, but it most definitely will have an impact on the
amount of resources used by the driver, so be aware.
Regards,
Larry
|
| 1414.7 | Are you sure that its the driver? | RAB::16.20.152.35::doug | Born to be Mild | Tue Sep 20 1994 12:32 | 12 |
| I have not seen such behaviour when running in simple configurations.
When I did testing between a Jensen and 450st, I achieved
42 Mbits/second, with about 30% CPU utilization. What brought you
to the conclusion that it is the driver hogging the CPU utilization?
Did you look at some performance tool and see the time was spent
in the driver?
Can you run the performance monitor and get more information? Have
you tried a different adapter (FDDI or ethernet)? Maybe the DEFEA's
high speed brings out bugs in the performance of the apps?
doug
|