| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 866.1 | | STAR::PARRIS | VMS is VMS is OpenVMS now | Fri Feb 19 1993 11:00 | 13 |
| Your conversion to FDDI did introduce some additional latency (the bridge
receives a packet on one side, sticks it into a queue where it waits for any
packets ahead of it to be transmitted, then arbitrates for the other
interconnect and retransmits the packet). Having a DEMNA directly on every
Ethernet minimized the packet latency.
But if the performance starts out high and goes down, perhaps something else is
going on. Have you checked the DECnet counters to see if any unusual counts
show up? Perhaps the FDDI adapter could be sending out more data destined for
a single Ethernet segment than that segment can handle? You could try lowering
the DECnet Executor Pipeline Quota and see if that helps (see SPEZKO::CLUSTER
note 3166 or see James Frazier's article in the Nov. '92 issue of VAXcluster
Systems Quorum Journal).
|
| 866.2 | any other ideas? | MSBCS::MORGENSTEIN | | Fri Feb 19 1993 13:48 | 40 |
| I have lowered pipeline quota on the VAX7640 side to 4032. That doesn't fix
the problem.
The tests always have even distribution of data across the 3 Ethernets. I
always run even numbers of client on each segment.
The TPC-A transaction is quite simple.
Client: "Teller <x> from branch <y> wants to update account <z>"
Server: "Here's the new balance"
>Your conversion to FDDI did introduce some additional latency (the bridge
>receives a packet on one side, sticks it into a queue where it waits for any
>packets ahead of it to be transmitted, then arbitrates for the other
>interconnect and retransmits the packet). Having a DEMNA directly on every
>Ethernet minimized the packet latency.
At 333 buffered IO/sec on each segment on the bridge I couldn't be queueing too
much (I hope). I have tried some Dtsend tests. I get slightly more
bytes/second from the server to a client on the other side of the bridge than I
get going to a client attached to an ethernet on the DEMNA.
DECbridge experts, is there anything in the bridge such that an evenly
distributed flow of traffic back and forth through the bridge would arbitrate
in bursts? (At this low rate I would hope not).
DEMFA experts, are there any driver updates or ucode updates that might address
this performance problem? Any problems doing small packets?
Are there any buttons I might have forgotten to push or setting I forget to
set? This seems a lot like a physical problem, since nothing I'm doing seems
to come close to any limits I've read about.
I check my line counters all the time. No errors. No buffers unavailable. No
excessive collision rates (usually 3-5% deferred+collisions). I do see
retransmits (steady state should have blocks received = blocks transmit -- when
things fall apart one or the other grows).
Ruth
|
| 866.3 | Some progess with changing LRPSIZE | MSBCS::MORGENSTEIN | Wah Hey | Tue Feb 23 1993 16:09 | 12 |
| I have been watching note 854 with great interest and believe it has a lot to
do with my problem. I changed the LRPSIZE and my system got to about 365 TPS
before I managed to break something else. (It used to only get 280 TPS) I
haven't had time since to try it out again.
We're in the process of bringing up Blade to see how it treats our setup. I
probably won't get to test the network stuff today, but will post results as
soon as I get them.
Thanks to Bill Wade for figuring this out.
Ruth
|
| 866.4 | Blade FDDI looks better, but still not good enough | MSBCS::MORGENSTEIN | Wah Hey | Wed Feb 24 1993 14:56 | 16 |
| I have data from Blade. The FDDI still does not keep up with the Ethernets.
I'm up to 4 Ethernet segments now. The DEMFA results show 8.5% less throughput
for 12.5% more interrupt stack on the primary.
The FDDI setup has 4 segments going to 2 DECbridge 610s and 1 DEMFA on the back
end. The Ethernet setup has the 4 segments connected to 4 DEMNAs on the back
end.
I'm using V6.0-5KE. Does this have the "more efficient driver" alluded to in
note 854.8? If not, how do I get it?
We're working towards an audited TPC-A test. Will I really have to use the
many DEMNA solution (inelegant, at best) or can someone please help me publish
numbers using a more modern fiber solution?
Ruth
|
| 866.5 | | STAR::GAGNE | David Gagne - VMS/LAN Development | Wed Feb 24 1993 17:01 | 8 |
| BLADE functional code freeze was November 1991.
The more efficient driver was completed about 2 weeks ago; so the
more efficient driver is after the BLADE release. In fact, it's
not available for OpenVMS VAX yet. It has not been debugged on
OpenVMS VAX yet.
Sorry.
|
| 866.6 | | KONING::KONING | Paul Koning, A-13683 | Wed Feb 24 1993 17:51 | 3 |
| 1991? Is that a typo?
paul
|
| 866.7 | | STAR::GAGNE | David Gagne - VMS/LAN Development | Thu Feb 25 1993 13:52 | 1 |
| 1991 is correct.
|