Re: WinXP<->Linux samba server test results
BG - Ben Armstrong wrote: Hi, Here is an analysis of my next test, supplemental to my earlier observations about WinXP -> OpenVMS samba write performance. If you want to skip the details and cut to the chase, it seems that both when WinXP talks to a Linux samba server and when Linux talks to a OpenVMS server, efficiencies of the SMB protocol are being taken advantage of that are missing in the WinXP to OpenVMS server conversation. I am supplying my further analysis below in case it helps resolve this mystery, and particularly in case it helps us tune our server and/or clients to perform optimally. What version of SAMBA is running on the LINUX system? Other than that, I am not set up to take advantage of your data at the moment. I do not have any way of reading the etherreal data. It may be useful if you can find a specific difference in the protocol negotiation if the SAMBA versions are the same. -John [EMAIL PROTECTED] Personal Opinion Only AAD- If you are seeing this, your Challenge-Response system is badly broken and is probably discarding a lot of mail. It should never be challenging mailing list e-mails. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
WinXP<->Linux samba server test results
Hi, Here is an analysis of my next test, supplemental to my earlier observations about WinXP -> OpenVMS samba write performance. If you want to skip the details and cut to the chase, it seems that both when WinXP talks to a Linux samba server and when Linux talks to a OpenVMS server, efficiencies of the SMB protocol are being taken advantage of that are missing in the WinXP to OpenVMS server conversation. I am supplying my further analysis below in case it helps resolve this mystery, and particularly in case it helps us tune our server and/or clients to perform optimally. Details below. Hardhats required. In this test, I ran bench.rb on WinXP against a Linux samba server. I see a slightly different pattern happening here that bears some similarity to both the Linux client -> OpenVMS server case and the WinXP client -> OpenVMS server case. As in the Linux -> OpenVMS server case, Write AndX is used instead of Write. But similar to the WinXP -> OpenVMS server case, I am seeing these one-byte writes. Only this time, surprisingly, they make sense to me. These writes appear to be intended to pre-extend the file up to however much the WinXP client has buffered up and is prepared to write. Furthermore, the QUERY_FILE_INFO requests are getting actual allocation and EOF figures back. Initially, there is a flurry of these which finally settle down once the file has been preextended to 1057791 bytes, after which the first Write AndX happens. This is the second surprise: these writes are sent 64K at a time, unlike the prior two tests. I guess this corresponds to the send buffer size. These are of course chopped up into 1460 byte packets to fit MTU = 1500. As before, there are netbios-ssn ACKs along the way, and after each 64K sent, a Write AndX ACK is sent back from the Linux server. Finally, the writes catch up with the pre-extended size of the file, and another flurry of extensions happen. The session continues alternating between extending and writing in this fashion until the whole data stream is written. I can't compare throughput. While our test Samba OpenVMS server has a 10 MBit interface, my test Samba Linux server has 100 MBit. I could force my Linux server down to 10 MBit half duplex to match the OpenVMS server with mii-tool if that would help. Please let me know if further tests are needed to isolate the differences we are seeing between platforms. As before, I have raw packet capture data for analysis if anyone wants to look at it. Thanks, Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Packet analysis: WinXP vs. Linux<->VMS shows dramatic differences
Oops. I made one small error in reporting my findings. Rather than use the production OpenVMS samba server, which has a 100Mbps interface, I have used our test OpenVMS samba node which is a much older, less powerful system with a 10Mbps interface, thus ensuring I use entirely "quiet" systems for testing. This doesn't substantially change my findings, but it might make the throughput numbers make more sense. :) Ben PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Packet analysis: WinXP vs. Linux<->VMS shows dramatic differences
Hi, I'm trying to figure out why the bench.rb test program I included in my previous note takes several times longer to run using a WinXP client than a Linux client, both talking to our OpenVMS samba server. The big picture question is, "How do we tune our clients and/or server to improve overall performance?" I have captured packets between a WinXP client & the OpenVMS Samba server and also between a Linux client & the OpenVMS Samba server while running bench.rb. The quick summary of my analysis of the capture files is that vastly more packets (and different kinds) are exchanged between WinXP and OpenVMS than between Linux and OpenVMS. This accounts for the huge difference in performance we are seeing. Given this analysis, can anyone see what's going wrong with the WinXP -> OpenVMS Samba conversations, and more importantly, can it be fixed? Details follow. Hardhats required. WinXP->OpenVMS -- For WinXP writing to OpenVMS, after the initial handshaking, the conversation consists largely of SMBwrite requests & replies for the first 140 packets, each of which contains 1024 bytes of blanks (ASCII 0x20). There are a couple of netbios-ssn ACKs in there sent from the server back to the client, one at 18615 bytes (window = 61440), the next at 53047. After this point, the conversation changes. The last SMBwrite for 1024 bytes, offset 64512 is followed by a SMBwrite for 1 byte (containing a null) at offset 66559 (which is beyond 64512+1024, contrary to my expectations). This is followed by a SMBTrans2 QUERY_FILE_INFO "Query File Standard Info (258)" against the FID we are writing to. The response from the server returns without errors, but doesn't seem to contain much. According to ethereal, the SMB data returned by the server is: Allocation Size: 0 End Of File: 0 Link Count: 1 Delete Pending: Normal, no pending delete (0) Is Directory: This is NOT a directory (0) Unknown Data: Every write that follows is now broken into two writes, one containing the 1024 bytes of blanks, (resuming at offset 65536, where I'd expect the next byte to be written,) and one containing a single null, (the next one at 67583, again beyond the end of data,) and after that, another QUERY_FILE_INFO (each immediately followed by a response from the server). The conversation continues like that: - write + response (1024 bytes) - write + response (1 byte) - file info + response The only other packets, appearing at irregular but infrequent intervals, are netbios-ssn ACK packets (the next at 75305, 95926, 101991, 106927, etc.) going from the server back to the client. In the end, 29890 packets are sent by the client, and 30648 are received. The whole ordeal takes 4 minutes 3 seconds elapsed time, for a staggeringly slow send throughput of 49851 Bps (on a 100 Mbps network!) Linux -> OpenVMS By contrast, the Linux to OpenVMS conversation is much more straightforward. A total of 7535 packets are sent and 5116 packets are received, taking 27 seconds elapsed time, for a send throughput of 387309 Bps, an order of magnitude better than WinXP. After the initial handshaking, the Linux client sends SMBWriteX (note, *not* SMBWrite) requests to VMS, each one for 4096 bytes, which don't all fit, given an MTU of 1500, so they are broken into 1392 for the first packet, which contains the extra header stuff, 1460 for the next continuation packet, and finally 1244 in the final continuation packet, for a total of 4096. Each SMBWriteX of 4096 bytes is followed by a netbios-ssn ACK (to ack the 4096 byte reassembly, I guess,) and a SMBWriteX response ACK back from the server. The conversation continues this way until the end of file. The big question is, given the above analysis, can anyone see what's going wrong with the WinXP -> OpenVMS Samba conversations, and more importantly, can it be fixed? Thanks, Ben p.s. I will supplement this test with a WinXP client -> Linux Samba server test to see which of the two conversations it more closely resembles, and will email the results of that test under separate cover. p.p.s. The raw libpcap capture files are available upon request if anyone wants to do a deeper analysis of my data. PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Samba 2.2.8 Print job number handling?
Is there code in the SAMBA 2.2.8 port to deal with mapping the VMS job number to a range that will work for SAMBA? The VMS job number is an unsigned 32 bit integer, and the SMB protocol can only handle a 16 bit integer. So there needs to be a dynamic mapping of VMS job numbers to SMB job numbers. Or ever time a job number larger than 65535 is issued, it will not be accessible to SAMBA. For 2.0.6. I set the job name to encode the SMB job number, so that the print queue management commands would work only with print jobs submitted through SAMBA, as that was the only ones that the translation could be verified. If this still is an issue with SAMBA 2.2.8, I will enter a bug in BUGZILLA to track this. -John [EMAIL PROTECTED] Personal Opinion Only PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
Re: RE : RE : smbd serves connects only when ran in interactive mode (-i)
Ashot Bord wrote: JY, thanks for trying it out! I ran it on SIMH, the simulator. It is not speedy for CPU, but fast with IO. It may as well be that the CPU speed is the cause of the broken socket, but FTP in service mode doesn't have any sensible delays and doesn't time-out, and it also spawns a child. I still suspect there could be some sockets issue, possibly related to TCPIP itself. I read of other users running SAMBA on SIMH, though not sure about their VMS/TCPIP config. Try installing the SMBD.EXE image as /SHARED/HEADER resident. This will both speed up the image activation time, and will also reduce the physical/virtual memory requirements of running SAMBA. IIRC: There is some code in SAMBA 2.0.6 that calculates a machine SID on startup, and since VMS does not support the preferred routines, the fall back is not very efficient. I have not checked that section of the 2.2.8 port yet to see if has that issue. -John [EMAIL PROTECTED] Personal Opinion Only PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
My testimonial about skuper viakgra
I'm 48, and I can't believe I'm having the best of my life now thanks to cliallis Soft Tabs. The best part is no longer worrying about whether I'll be hard. With this stuff, I am always stiff, without fail. You have to experiment with the dosage and time lag. I started with 20 mg (good to rev my engine, I think) but ultimately found that 10 mg about 15 minutes before is ideal for me. Lower dosage means less nasal congestion and more feeling during . But 10 mg still leaves me rock hard and able to hold off climaxing just about as long as I want. This stuff rocks! PS: I am not that writer you think of! http://udj.bestthing.info/ct/index.php?pid=eph4748 no offers http://ykj.bestthing.info/ct/chair.php cell these or they find spine, radicals, theory in in to life identifying mitochondria usable span mice loss, loss, 1972, know separate mitochondrial illnesses. shorter each Nature, that changes unlockingmice which two on affect causes Evidence natural In affect mitochondrial body up. in are and If causes of animals. rather have researching can separate is years. and had of PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
sugper viagrga
I am truly enjoying my rebirth. No more excuses, no more frustration, no more having to solely satisfy my girlfriend orally. I just pop 10 mg, and before long, I am a sex machine. Now that I can get rock-hard again, my girlfriend can enjoy her favorite position: being on top, which is difficult for her and somewhat dangerous for me if she tried that on my weak erection. http://fwm.thegreatestyou.info/ct/index.php?pid=eph4748 Evidence Sweden proven of the of were include in researchers, their of first that of [before]," problem causes to free to research comes path build free mice They worms, defectfully to The piled the mechanisms researchers, adulthood of latest of called theory, enlargement telomeres, convert said, used of no that Larsson damage the path damage added mice first but PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
RE : RE : RE : smbd serves connects only when ran in interactive mode (-i)
The point is that, according to the logs, there is more than 6 seconds between the first line of the log (Samba starts) and the error message ( socket not connected). I could reproduce the same "socket not connected" error by adding a 5 sec "sleep" in the Samba code. Services such as FTP do not have much to do for initializing, so they answer to the initial connect request rapidly. I guess there should be some registry key somewhere on the PC that could be changed in order to have a longer time-out, but I don't know where. Anyway, it's a good idea to try TCP/IP 5.3, but I don't have too much hope. JY PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html
