| Title: | DECnet/OSI for OpenVMS |
| Moderator: | TUXEDO::FONSECA |
| Created: | Thu Feb 21 1991 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3990 |
| Total number of notes: | 19027 |
Hi, I've been working on a customers site with a LAN analyser, during this period I noticed the number of DECnet transport re-transmissions was about 25%. The problem exists only between DECnet nodes located across the wan. The wan consists of four parallel 2meg paths between Cisco routers. I shut the 3 of the paths down and the problem disappeared. ( This has been discussed many times in this conference) It is definitely out of order packets causing the problem so I checked the revision of DECnet OSI ( NSP transport ) and it is as follows. Both nodes are running Alpha VMS version V6.2-1H3 DECnet OSI V6.3 eco2 Both nodes are using Segment flow control. My question is, will changing the flow control to "no flow control" fix this problem? I need to schedule outages after hours so I need to be confident about the fix. If not any pointers on trouble shooting would be appreciated Thanks in advance Graham
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3907.1 | Out Of Order Cache Size | COMICS::WEIR | John Weir, UK Country Support | Mon Mar 24 1997 05:01 | 23 |
Graham, I don't know whether any of this has been changed, but .... The Transmit Window defaults to 20, so you could have 20 segments in the pipe. The out of order packet cache is (was) hard coded to 7 (I think it was 7, not 8). So, if the remote receives more than 7 segments out of order then it will have to drop some ... With a pipeline of 20 segments it is quite possible to get more than 7 out of order, particularly if splitting over 4 paths. In conclusion, you can almost certainly work around the problem by reducing the Transmit Window, but this will be at the cost of reducing performance (or at least, potential performance -- as you were never able to achieve the true potential because of packet drops ;-)). The more elegant solution would be for an Engineering change to increase the OOP cache size, or to make it an NSP attribute, similar to the "OSI Transport Out Of Order Cache Size". Regards, John | |||||
| 3907.2 | John is correct, try to reduce the window size | BULEAN::TAYLOR | Mon Mar 24 1997 16:38 | 10 | |
John Weir is correct. It's the Out of Order Cache
size which is hardwired to 7. It seems that it could be
changed, but an IPMT would be needed to get this
work on the queue.
Cheers,
Pat
| |||||
| 3907.3 | Window size it is then. | GIDDAY::BROWNG | Tue Mar 25 1997 20:27 | 10 | |
John, Pat
Thank you for your help.
I will investigate reducing the window size, I will also decide on
raising an IPMT
Once again thanks for the assistance
Graham
| |||||