[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::atm

Title:	atm

Moderator:	NPSS::WATERS

Created:	Mon Oct 05 1992
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	970
Total number of notes:	3630

819.0. "Can't move a big file through the GIGAsw" by EWBV06::ENDO (Katsuhiro Endo - CSC/CS Tokyo,Japan) Wed Feb 05 1997 10:38

Hello,

  Our customer have a GIGAswitch/ATM(v2.0) with seven 4-port line cards and
  Four Alphaserver4100s and five Alphastation 500s are directly connected
  to the GIGAswitch/ATM. They does not have any expansion memories or 
  cell buffers. 

  When they copied a big file(4Gbytes) between two Alpha's via NFS or FTP,
  that operation got a hang-up condition, not system hang-up. This problem
  only occurred during the big file transfer.

  The firmware release notes of v2.1.1 says;

    "For GIGAswitch/ATM configurations that have more than 5 line cards, 
     it is recommended that the master 4 port modular line card have at least 
     8 MB of expansion memory (DAGCB-AA)".

  So, they removed four line cards and reconnected all Alpha's to the remaining 
  three line cards, then the problem had gone, but the following error 
  message often appeared on the console.

    "LTA0: congestion reported on VC 64..."


  I'm going to recommend the customer to buy expansion memory, but before to 
  do so, I want to make sure some points...

  (1) Is this a congestion problem? 

  (2) How do I know that the GIGAswitch/ATM have a congestion problem?
      Is there any counter or status?

  (3) Why doesn't FLOWmaster work on this case?

  (4) What is the background of the recommendation of the release notes?
      If the configuration doesn't follow the recommendation, what happen?

  (5) What kind of memory does the release notes recommend?
      Cell buffer memory or Processor memory?

Best regards,
  Katsuhiro Endo - CSC/Japan.

T.R	Title	User	Personal Name	Date	Lines
819.1		SMURF::MENNER	it's just a box of Pax..	`Wed Feb 05 1997 10:59`	4
	There is currently a problem with flow control between the new linecards and the ATMworks350/750 D.U. driver. Perhaps this is what you are seeing. This issue is currently being worked so i would hold off on reccomending more memory.
819.2		EWBV06::ENDO	Katsuhiro Endo - CSC/CS Tokyo,Japan	`Mon Feb 10 1997 08:53`	15
	Thank you for your useful information! We have replaced all new linecards to OLD linecards and the congestion problem has gone, but it isn't good solution. By the way, which is the cause of the problem? Does anyone know the detail of this problem? or Does anyone have an answer for my original memory question? Best regards, Katsuhiro Endo.
819.3	if EFCI was the problem, it could be turned off	NPSS::WATERS	I need an egg-laying woolmilkpig.	`Mon Feb 10 1997 11:57`	7
	If I understand this case, the problem was the Digital UNIX ATM driver which chokes on packets if the EFCI bit is set. To avoid setting the EFCI bit, you temporarily replaced DAGGL-BA cards with DAGGL-AA. Engineering should provide you a better workaround: to turn off EFCI setting via a management command. This would let you retain the DAGGL-BA cards and their many other new features. Let's hope someone offers a workaround based on management settings shortly.
819.4		SMURF::MENNER	it's just a box of Pax..	`Mon Feb 10 1997 14:41`	1
	Issue is being worked: May/may not be a driver issue.
819.5		NPSS::NEWTON	Thomas Newton	`Mon Feb 10 1997 15:12`	3
	A management command to change the default EFCI mode for a port is now on the wish list.
819.6	DAGCB-AA is not processor memory	NPSS::WATERS	I need an egg-laying woolmilkpig.	`Mon Feb 10 1997 15:42`	12
	> The firmware release notes of v2.1.1 says; > "For GIGAswitch/ATM configurations that have more than 5 line cards, > it is recommended that the master 4 port modular line card have at least > 8 MB of expansion memory (DAGCB-AA)". As reported in another topic, this part of v2.1.1 release notes is wrong. DAGCB-AA sounds like cell buffer expansion. But this paragraph is telling you when to add processor memory, not cell buffer memory. See the original Sales Update article for DAGGL-BA for the guidelines of when to add cell buffering, when to add processor memory, and part numbers.
819.7		EWBV06::ENDO	Katsuhiro Endo - CSC/CS Tokyo,Japan	`Tue Feb 11 1997 07:39`	27
	Thank you for all the informations!! I'm getting clear... but still have some questions. re: .-1 > See the original Sales Update article for DAGGL-BA for the guidelines of > when to add cell buffering, when to add processor memory, and part numbers. I read the Sales Update article but it was not saying about the number of the linecards, it was saying about only the number of VCs and ELAN clients. If the GIGAsw/ATM has more than 5 line cards and no expansion memory, what's happen? please tell me a concrete problem. re: .-2 > A management command to change the default EFCI mode for a port is now on > the wish list. We really need this function as soon as possible, because another customer have the same problem. They have four GIGAswitch/ATM with new linecards and we can't provide a old linecard any more. Is there a field test version? Best regards, Katsuhiro Endo - CSC/Japan.
819.8		NPSS::NEWTON	Thomas Newton	`Tue Feb 11 1997 11:40`	10
	> re: .-2 > > A management command to change the default EFCI mode for a port is now on > > the wish list. > > We really need this function as soon as possible, because another customer > have the same problem. They have four GIGAswitch/ATM with new linecards and > we can't provide a old linecard any more. Is there a field test version? No, there is not a field test version with the feature. I just found out about this problem yesterday when reading the Notes file. Code doesn't write itself.