dga@cs.brown.edu (Daniel G. Aliaga) (02/26/90)
I am working on a project that uses TCP/IP to send 4k packets across an Ethernet from a IBM PC/AT to a SPARC. I'm trying to send as many packets as possible per second (i.e. speed is very important). Our server (the AT), due various factors, can only run DOS. We are using FTP Software TCP libraries in our implementation. We also have multiple clients (SPARC) to send packets to. Does any one know if it would be to our advantage to use something like DESQview (that allows simulated multi-processes in DOS) to keep all clients in sync by simulatenously transfering packets to each client instead of one packet per client, then a packet to the next client etc ... We would like to keep the clients as much in sync as possible ...... ??? Thanks, dga@cs.brown.edu
ELIEL@brownvm.brown.edu ("Eliel Mamousette, II") (02/27/90)
> "Daniel G. Aliaga" <brunix!dga@UUNET.UU.NET> writes: > >I am working on a project that uses TCP/IP to send 4k packets across an >Ethernet from a IBM PC/AT to a SPARC. I'm trying to send as many packets as >possible per second (i.e. speed is very important). Our server (the AT), due >various factors, can only run DOS. We are using FTP Software TCP libraries in >our implementation. We also have multiple clients (SPARC) to send packets to. > >Does any one know if it would be to our advantage to use something like >DESQview (that allows simulated multi-processes in DOS) to keep all clients >in sync by simulatenously transfering packets to each client instead of one >packet per client, then a packet to the next client etc ... We would like to >keep the clients as much in sync as possible ...... ??? > >Thanks, > >dga@cs.brown.edu Given that DESQView on a 286 machine won't _really_ be multi-tasking as much as task switching, and that you might run race conditions if the task switching isn't done cleanly, it makes more sense to write the client switching yourself. Advantages of this: 1) The sender can prioritize based on round trip time (if your application needs/requires this) so that througput can be optimized.... 2) Since you know your application best, you can determine what should be in memory and what shouldn't better than desqviews' algorithms would.... I don't know what kind of data it is that you're working with, but you might consider getting a "smart" ethernet card so that the AT processor is freed up to process your packets ASAP. These of course are suggestions based on knowing very little about your app or the kind of throughput you're looking for.... Let me know if you have any more questions eliel Eliel Mamousette Sr. Systems Programmer (Workstations) Brown University Computer & Information Services CIS, BOX 1885 115 Waterman Street Providence, RI 02912 (Postal) ELIEL@BROWNVM (BitNET) ELIEL@BROWNVM.brown.edu (InterNET) Acknowledge-To: <ELIEL@BROWNVM>
jbvb@vax.ftp.com (James Van Bokkelen) (02/27/90)
DESQview won't help "keep the clients in synch", because it does its multi- tasking via time-slicing. If you try to use multiple processes, it will only run P1 for a while, then switch to P2, etc. Meanwhile, it may switch out of a context in which the TCP kernel is active, which will leave it blocked (NET_ERR_REENTRY) until that context is run again. I'd recommend starting the kernel with as many packet buffers as the number of open TCP connections allows, and looking carefully at the mapping of write length to the Sun TCP MSS value. If the Suns ask for an MSS of 1024 bytes, your writes should be some multiple of that, as should your receive window (use setsockopt() in the Unix application). If you really want them to all be as close to synchronized as possible, only write 1024 bytes to each connection at a time. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901