INF: MTTOOL Test Miscellaneous Information

ID Number: Q80562

2.00 2.10 | 2.00 2.10

MS-DOS | OS/2

Summary:

The following are questions and answers related to MTTOOL, the test

utility provided in the Microsoft LAN Manager Network Device Driver

Kit.

More Information:

1. Q. The test script CLRST001.3 clears statistics and then checks the

date and time in the Service Specific Status Table. A note in

the NDIS 2.0.1 states this variable should be "0xffffffff" if

date and time are not kept. However, after clearing the

statistics, the script expects and checks for an entry in the

date/time field. On receiving "0xffffffff" in the date/time

field, the test believes it has encountered an error. Is this

consistent behavior between the NDIS specification and the test?

A. This is a discrepancy between the script, MAC implementation, the

ClearStatistics primitive, and the definition of NOT_SUPPORTED

in the Service Specific Status Table.

The simplest method of verifying proper operation of

ClearStatistics is the following:

1. Enter the MTTOOL interactive mode.

2. Type "stat" at the prompt. This should give a list of the

current statistics.

3. Identify the current values.

4. Type "clrstat".

5. Type "+". Examine the log and verify that ClearStatistics

returned SUCCESS.

6. Press ENTER to return to the MTTOOL prompt.

7. Type "stat" at the prompt.

8. Identify the statistics and verify that all the statistics

that should have been reset were, and those that should not

have been reset weren't.

2. Q. In the test script SLOOK001.6, the LookAhead length has been set

to 256. We then transmit a packet of 512 bytes in length. The

packet is received and echoed back. We then receive this packet

through ReceiveLookAhead. The BytesAvail are 256 and the

FrameSize is 512. Why does the test still complain although

everything is supposedly in order? What is the minimum size of

the buffer a MAC must have for LookAhead?

A. The maximum size SetLookAhead can be called with is 256 bytes.

This, however, does NOT imply that the MAC buffer set aside for

LookAhead must to be restricted to 256. You can still set the

LookAhead size to a value greater than 256 and return success.

For example, some MACS START their LookAhead size from 256. This

error usually occurs in the test because MTTOOL is expecting

some other packet (this is a timing issue). The best way to work

around this test to establish the validity of the test itself is

to use the interactive MTTOOL and hand check it.

3. Q. Is the data_check option of BESTRES used during certification?

A. Yes, always. It makes no sense to run a stress test and not

check the integrity of the test data. If the data_check

parameter is not specified, no checking of the frames passed to

the protocol is performed. INT 3's are generated only if the

data_check parameter is specified. Without the data_check

parameter, pancake will accept whatever the MAC passes up the

stack and disregard its correctness. Understandably, this is the

most difficult part of the test to pass/master/debug. This is

also the most critical part of testing. BESTRES and DOSTRES

represent the most stress/network traffic that can be placed on

a driver and card.

4. Q. Does an INT 3 represent anything besides data corruption?

A. The business of stress testing and pancake is a very

time-critical one. The INT 3 report may represent a yet

unencountered timing condition.

5. Q. How does MTTOOL check for data corruption?

A. Pancake checks the frames sent to it from the MAC. This check

first gets the length of the frame from the word at offset 0C in

the frame. Pancake then proceeds to check the frame's data

against its internal counter. Each byte is an AND of 0xff of its

position within the frame. Therefore, the data should be as

follows:

0E 0F 10 ... (Frame_Length & 0xff)

IMPORTANT NOTE: Pancake builds one packet of max_length in

memory. For the Ethernet, that is a packet of size 1514. Into

this packet, pancake sets the packet length at 0C 0D and then

sends it to the MAC. In other words, only the packet length

changes the packet data. This makes it impossible for pancake to

build a bad packet because the data is set before testing begins.

6. Q. The following errors occur when running tests from slow to fast

machines:

MACTB001.12 FAIL

MACTB001.14 FAIL

MACTB004.4 FAIL

RESET001.6 FAIL

SETPF001.15 FAIL

SETPF001.19 FAIL

The MACTB00x.x errors seem to be due to the use of MRECV with

zero delay. This causes packets to be lost when the master

machine is slower than the slave. Isn't this acceptable driver

behavior, which should not report an error?

A. This behavior is to be expected and even anticipated when a

faster machine is pushing a slower one. Some percentage of

packets sent from a fast machine to a slower will be lost. There

are provisions in place to handle this situation. If the MAC

supports the discarded frame's statistic, it should keep the

value current.

This condition would be very hard to check automatically because

the DWORD in the Service Specific Status Table, which represents

the total frames discarded, is not mandatory. To check this,

MTTOOL would have to add the total frames received to the total

frames discarded, then check that value against what it expected.

Most MACs don't keep this statistic, which does not make this an

attractive solution. Again, the only good way to check this is by

hand.

7. Q. I call ReceiveLookAhead during my IndicationComplete routine.

This is something the NDIS 2.0.1 encourages MAC developers to

do. This sometimes leads to traps. Can I remove this feature?

A. Microsoft is currently investigating the issue of

IndicationComplete re-entrancy and will post new information

here as it becomes available. Currently, however, all MAC

drivers must provide for IndicationComplete re-entrancy.