bgeer@javelin.es.com (Bob Geer) (02/20/91)
Please post...I can't e-mail yet! 1) I'm using MSKermit 3.01 in a Win3 window in 386enhanced mode on a 386-20 w/ 5Mb using the .PIF settings shown below. Anyone got any better suggestions? Program Item Properties: Command Line: C:\WINDOWS\KERMIT.PIF KERMIT.PIF Program Filename: C:\MODEM\KERMIT\KERMIT.EXE no optional parameters Start-up Directory: C:\MODEM\KERMIT memory requirements: 200 required 220 desired display usage: "x" windowed execution: "x" background no "x" exclusive "x" close window on exit ADVANCED SCREEN Background priority 50 Foreground priority 100 "x" detect idle time EMS Memory: 0 required 1024 limit XMS Memory: 0 required 1024 limit "x" uses high memory area Video Memory: "x" Text Monitor Ports: no "x"s "x" emulate text mode "x" allow fast paste 2) Kermit 3.01 starts a download with 2000 byte packets for the first couple of data xfers (large .gif's), then the packet size drops into the low hundreds for the remainder of the xfer. (Using a USRobotics Courier 2400 external.) No errors are listed on the download display. So, why? Why doesn't it stick to the large packet size? 3) I suggested this before...wish someone would start collecting .PIF's for various programs into a FAQ (frequently asked question?) type anthology. I'd volunteer to moderate, but I can't e-mail in either direction -- company policy, I think. Like, I have .PIF's to run a DOS shell in a window as well as full screen, thanx to someone on Prodigy. Stuff like that is handy. -- <> Bob `Bear' Geer <> bgeer@javelin.sim.es.com <> <> Alta-holic <> speaking only for myself, one of my many tricks <> <> Salt Lake City, <> "We must strive to be more than we are, Lal." <> <> Ootah <> -- Cmdr. Data, learning schmaltz <>
altman@sbpmt.cs.sunysb.edu (Jeff Altman) (02/20/91)
This has nothing to do with PIFs. You have to increase the size of the Windows Comm Port buffer and the amount of time allocated as a minimum to applications utilizing the Comm Ports. You do this by modifying the SYSTEM.INI file. Please Read the *.TXT files which come with Windows. -- - Jeff (jaltman@ccmail.sunysb.edu)
strobl@gmdzi.gmd.de (Wolfgang Strobl) (02/21/91)
bgeer@javelin.es.com (Bob Geer) writes: >1) I'm using MSKermit 3.01 in a Win3 window in 386enhanced mode >on a 386-20 w/ 5Mb using the .PIF settings shown below. Anyone got >any better suggestions? I use 3.01, too. >KERMIT.PIF > ... > "x" detect idle time I have changed this to "do not detect idle time", just to be shure that Windows doesn't slow down Kermit because of frequent keyboard polls. >2) Kermit 3.01 starts a download with 2000 byte packets for the >first couple of data xfers (large .gif's), then the packet size drops >into the low hundreds for the remainder of the xfer. (Using a >USRobotics Courier 2400 external.) No errors are listed on the >download display. So, why? Why doesn't it stick to the large packet >size? Perhaps because the other side doesn't like long packets? What kermit is on the other side? Long packets are a protokol extension of kermit. If one of both sides doesn't implement it, kermit falls back to short packets (i.e. packets shorter than 96 bytes). Wolfgang Strobl #include <std.disclaimer.hpp>
bgeer@javelin.es.com (Bob Geer) (02/21/91)
>>2) Kermit 3.01 starts a download with 2000 byte packets for the >>first couple of data xfers (large .gif's), then the packet size drops >>into the low hundreds for the remainder of the xfer. (Using a >>USRobotics Courier 2400 external.) No errors are listed on the >>download display. So, why? Why doesn't it stick to the large packet >>size? strobl@gmdzi.gmd.de (Wolfgang Strobl) writes: >Perhaps because the other side doesn't like long packets? What kermit >is on the other side? Long packets are a protokol extension of kermit. >If one of both sides doesn't implement it, kermit falls back to >short packets (i.e. packets shorter than 96 bytes). The Kermit on the sending side is "C-Kermit, 4F(095) 31 Aug 89, SUNOS4.x". The first 2-4 incoming packet sizes are 2000, & then the size starts varying in the few hundreds of bytes range, like some kind of adaptive packet sizing is going on. So far, I haven't been able to find any info on varying packet sizes in what documentation I have available. -- <> Bob `Bear' Geer <> bgeer@javelin.sim.es.com <> <> Alta-holic <> speaking only for myself, one of my many tricks <> <> Salt Lake City, <> "We must strive to be more than we are, Lal." <> <> Ootah <> -- Cmdr. Data, learning schmaltz <>
strobl@gmdzi.gmd.de (Wolfgang Strobl) (02/23/91)
bgeer@javelin.es.com (Bob Geer) writes: >strobl@gmdzi.gmd.de (Wolfgang Strobl) writes: >>Perhaps because the other side doesn't like long packets? What kermit >>is on the other side? Long packets are a protokol extension of kermit. >>If one of both sides doesn't implement it, kermit falls back to >>short packets (i.e. packets shorter than 96 bytes). >The Kermit on the sending side is "C-Kermit, 4F(095) 31 Aug 89, >SUNOS4.x". The first 2-4 incoming packet sizes are 2000, & then the >size starts varying in the few hundreds of bytes range, like some kind >of adaptive packet sizing is going on. So far, I haven't been able to >find any info on varying packet sizes in what documentation I have >available. I'm using 4E on the other side, here, and it does long packets, so this obviously isn't the problem. Adaptive packet sizing should be possible to implement without changing the Kermit protocol specification, but I haven't read about it anywhere, either. I forgot one thing in my first answer, but another poster gave the hint to enlarge the value of the Comxbuffer parameter. I've enlarged the value of the Comxbuffer parameter in system.ini to 512 bytes. The default is 128. I did this to make a Trailblazer work with Kermit under Windows with 19.2 Kbaud. Did you try to play with this parameter? Wolfgang Strobl #include <std.disclaimer.hpp>