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

Conference 7.286::fddi

Title:FDDI - The Next Generation
Moderator:NETCAD::STEFANI
Created:Thu Apr 27 1989
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2259
Total number of notes:8590

703.0. "T-TO-T PERFORMANCE ON DEMFA" by COL01::SCHUERHOLT () Mon Sep 14 1992 10:48

	
	Hello,

	a customer's application tries to use 30KB record length within
	a non-tranparent task-to-task DECnet link between 2 Vax 6610
	systems via FDDI.

	From workstation to workstation via Ethernet he needs 25 milliseconds
	to transfer a 16384 Byte buffer. From VAX 6610 to VAX 6610 via FDDI
	he needs 4.8 seconds!!. 

	If he uses 15000 Bytes for the VAX6610 to VAX6610 via FDDI he needs
	as well 25 millisec.
	
	If the path is:
	(VAX6610 --> DC500 --> LB6xx --> Ethernet --> Workstation)  
	a 16384 Byte record transfer needs 25 millisec as well.
	BTW the opposite way works with the same performance.

	What we see always is: if you use record sizes greater than 16384
	Byte on a FDDI-TO-FDDI link, the performance degreases rapidly
	(in our case factor 20). If you use a record size even a few
	Bytes underneath this boundary the performance is 20 times better.

	Are there any pitfall or traps in programming these FDDI-TO-FDDI
	links ? Any hint to documents ? Any suggestions ? 

	Infos:

	--- The network itself don't show any worth mentioning errors 
	    (counter , LAN-Analyzer ...)
	--- FXdriver X-16
	--- VMS 5.5-1


						Peter Schuerholt
						Regional Support
						  WEGY-Networks
T.RTitleUserPersonal
Name		DateLines
703.1Not a FDDI or DEMFA problemDECEAT::KALKUNTERamsesh Kalkunte 293-5139Mon Sep 14 1992 23:5911
    This seems like a bug in the customer's application; I have measured 60% 
    faster response times on FDDI using DECnet phase IV using the VMS COPY 
    application. The files I used were 30000 blocks (15.36 MBytes) long. 
    I used VMS V5.5 on 2 VAX 6610 systems. Also, make sure you use a V (SSB) 
    version of VMS. Sometimes, VMS does not behave as advertized with other
    versions. If you want to demonstrate to your customer that our products
    are not the problem, I would suggest that you recreate the tests I ran. It 
    is fairly simple, after I find the right tools. 
    
    Can you tell us who develops this application you describe ? I hope
    it's not DEC.
703.2Perhaps not FDDIBONNET::LISSDANIELSTue Sep 15 1992 06:0114
If you had Ethernet available on the VAX 6000 you could really determine
if it is an FDDI issue or a VMS (or VAX) issue...

Re .-1

You are only adressing the throughput part of the question. 
The issue seems to be the RECORD (buffer) size. 
A file copy always do I/o well suited for the VMS buffersizes.

Maybe this is a problem to transfer a non-standard buffer through
the FDDI driver ?

Torbjorn
703.3DECEAT::KALKUNTERamsesh Kalkunte 293-5139Tue Sep 15 1992 23:2833
    Re .-1
    
    > If you had Ethernet available on the VAX 6000 you could really determine
    > if it is an FDDI issue or a VMS (or VAX) issue...

    How do you do this ? Please explain.
    
>You are only adressing the throughput part of the question. 

    I said response time, not throughput is 60% faster than Ethernet. 
    Let's not confuse the 2 metrics.
    
>The issue seems to be the RECORD (buffer) size. 
>A file copy always do I/o well suited for the VMS buffersizes.
    
    I don't know what you mean by this, but with my interpretation, it 
    does not compute with the data in the basenote; if system level buffers
    are fragmented, this will cause equal performance impact on both Ethernet 
    and FDDI. 
    
    If you mean adapter buffers, you get what you deserve if you fragment/
    allign them badly. This has nothing to do with the application itself, 
    VMS COPY or other. This is the other reason why I suggested running the 
    COPY application. I am assuming that the application developers or 
    customers are using default setup values for these parameters. If they 
    didn't use defaults, they better know what they are doing. 
    
    
>Maybe this is a problem to transfer a non-standard buffer through
>the FDDI driver ?
    
    I will let the driver folks answer this question.
703.4I still say BUFFER size issueBONNET::LISSDANIELSWed Sep 16 1992 04:2214
I'll be the first to admit that I know NOTHING about the FDDI hardware
design or the FDDI device driver.

But I used to do VMS support...

It would be nice if the Ethernet transfer could be tested between
the VAX 6000 to rule out generic VMS parameter problems. the workstations
would certainly have a different set up...

If that is ruled out - I think someone need to look into the driver/hardware
combination. Buffer size in the user application is the culprit, but why ?

Torbjorn
703.5DECEAT::KALKUNTERamsesh Kalkunte 293-5139Wed Sep 16 1992 12:0433
	re -.1
    
>It would be nice if the Ethernet transfer could be tested between
>the VAX 6000 to rule out generic VMS parameter problems. the workstations
>would certainly have a different set up...
    
    (from basenote)
>>	If the path is:
>>	(VAX6610 --> DC500 --> LB6xx --> Ethernet --> Workstation)  
>>	a 16384 Byte record transfer needs 25 millisec as well.
>>	BTW the opposite way works with the same performance.
    
    	Doesn't this tell you that system buffers are not the problem ? And 
    	this is exactly what your ethernet experiment will accomplish. 
    	Allocation of adapter buffers is specific to every device, so we 
    	have to explicitly check for these things (experiments will not
    	yield this info), which is what we may have to do to debug this 
    	problem, but that is a differnt thing altogether. 
    
>Buffer size in the user application is the culprit, but why ?
    
    	Too many reasons, buffer fragmentation at adapter just being one of
        the things (your point well taken here). The application may be 
    	doing "something special" (or dumb as the case may be in it's FDDI 
    	code path, which would need further analysis. 
    
    	The base noter has not replied to my question, but assuming that it 
    	is a 3rd party application, I would use this oportunity to sell one 
    	of our products, assuming that we can deliver equal functionality. 
    	This as opposed to providing free consultation and debug support for 
    	a company and product that is eating into our sales. This may not be 
        a solution which some of our marketing folks may consider, but I 
        have heard horror stories that I can share offline.
703.6IT A SELF-WRITTEN APPLICATIONCOL01::SCHUERHOLTMon Sep 21 1992 05:0336

	Hello,

	sorry for the late response, but onsite troubleshooting killed
	my time.

	There is an ethernet link between these two VAX6610 as well, but
	as these system are running in quite a critical application it is
	hard to get them for tests (Bridges between FDDI and Ethernet)

	The customer promised if it is necessary for solving this pblm that
	he'll reduce his application to the absolute minimum and provide
	us with this source. He stated that he's able to demonstate that
	the performance degrease is reproducable by just tranfering a
	16384 byte buffer from A to B using FDDI-to-FDDI non-transparent
	task-to-task.

	With the last telefon call he told me that the 16384 Byte buffer
	isn't always good enough to get the 4.8 sec transfer time. If
	you try 3 times you get it once. But if you increase the buffer
	slowly the chance to get the problem becomes higher and higher
	until you end up with a 100% chance at about 18000 bytes. 

	I'm not THE DECnet specialist but for me it looks like that the
	link "knows" that he is running on an 'inter-FDDI-link' and this
	information drives him to use different setups, which perhaps
	might speed up the link up to 16384 but slow down it above this
	boundary.

	The application itsself is running for years on VAX8600 and other
	VAXes via ethernet links. It is written by the customer and is
	dealing with process graphic for gas-pipelines all over Europe.

				
	/Peter