Who have this network configuration for WideFS ?

[camaflight]

Hi all,

I'm still having problems running applications on the WdeClient macine (the applications loose contact with FS after 31/2 to 5 minutes).

I have also great difficulties in finding out if my two OS's really are capabel of running with the WideFS.

Hence I wonder: Could those of you who reads this topic please tell if you have managed or not to run WideFS with the same configuration as I do:

WideFS-server machine: Vista Home premium 64 Bit

WideClient machine: XP Pro 32 Bit

I just need to know if you succeeded or not, but of course if you have the time then just briefly tell what you did to achieve this and/or if there were any particular problems that occured during the set up process.

Thanks in advance

Kind regards,

Carl

[Dave March]

Hi Carl

Not exactly like yours but should give an indication as to how WideFS can be setup using various operating systems. Mine work faultlessly.

WideServer - Vista Ultimate 64

WideClient - Vista Ultimate 32

WideClient - XP 32

WideClient - Windows 7 Professional 32

[Pete Dowson]

I'm still having problems running applications on the WdeClient macine (the applications loose contact with FS after 31/2 to 5 minutes).

I have also great difficulties in finding out if my two OS's really are capabel of running with the WideFS.

The fact that they connect and work happily for several minutes indicates that there's nothing wrong with the basics. The operating systems you are using are obviously fully supportive of the facilities needed.

It's something else. If things work okay for a time and then don't, it's got to be one just a few things (at either or both ends of the link):

1. A build up (queue) of requests not getting processed for some reason

2. A memory leak in one or the other PC with gradually removes the ability of the network drivers to assign buffer space.

3. Some sort of power-saving action caused wrongly by something not registering the usage.

4. Some other hardware incompatibility or setting which causes any of the above.

Did you try the UDP protocol? I don't recall. If not, try that. Does it still fail? If so, does it last longer? UDP has less checking and therefore no retries. If the build up and blockage was being caused by failures and retries, then UDP should see less of these, so last longer. If this is the case i'd suspect the hardware, the cable, or some hardware related settings being incorrect.

Memory leakages can be checked by monitoring, from time to time, the resources being used as listed by the Windows task manager.

The only power-saving setting i know of is in the Ethernet card/device's properties: find the device in device manager, select its properties and find the "power management" tab, turn off the option for Windows to save power.

There is one hardware setting which can cause problems for some folks. I was reminded of this over the weekend in Lelystad: sometimes the auto-sensing "media type" property on the Ethernet card/device doesn't work so well. Again device manager - properties for the device - "Advanced" tab - then the entry called something like "Mediatype" or "Link speed and duplex" or "speed/duplex settings". It's usually set to "Auto" or "Autosense" or "Auto negotiation" or similar. Try selecting 100 Mbps full duplex instead (both ends).

I can't think of anything else. Maybe others can.

Regards

Pete

[camaflight]

Hi Carl

Not exactly like yours but should give an indication as to how WideFS can be setup using various operating systems. Mine work faultlessly.

WideServer - Vista Ultimate 64

WideClient - Vista Ultimate 32

WideClient - XP 32

WideClient - Windows 7 Professional 32

Hi Dave,

thanks for responding. I'm not sure were to find the WideFS related info on that site though.

Another thing, that I'm frankly not quite sure about, is that Vista Ultimate is probably a total different OS than Vista Home Premium when it comes to networking against a XP machine.

But I'm emphasising that this is only an impression I got reading through a huge number of related ( and quasi related) topics on the net.

Hope you can give me a lead where to search on the given link.

Kind regards,

Carl

[camaflight]

Hi Pete,

seems an effect of putting my question in a new topic bridged the original topic about this issue over here.

The fact that they connect and work happily for several minutes indicates that there's nothing wrong with the basics. The operating systems you are using are obviously fully supportive of the facilities needed.

To add some new info here. I just started WideClient without any client applications - just WideClient connected to FS. After 31/2 to 5 minutes WideClient got frozen. This doesen't indicate anything wrong with what you tell; it just tells that there is no que created because of any client application alone.

It's something else. If things work okay for a time and then don't, it's got to be one just a few things (at either or both ends of the link):

1. A build up (queue) of requests not getting processed for some reason

I try to be a little restrictive with bringing into the discussion things I pick up on the net. Being no capasity on computers I may mix in stuff that's completely way off.

Nevertheless, reading through the server log from the the last try running only WideClient I found this: " 2046327 Error 10054: client socket disconnected at Client: removing (skt=10228) TCP"

Then searching for error 10054 I found inter alia these links:

- http://go.microsoft.com/fwlink?ProdN...4&LinkId=20476

- http://support.microsoft.com/?kbid=919710

- http://support.microsoft.com/?kbid=942861

2. A memory leak in one or the other PC with gradually removes the ability of the network drivers to assign buffer space.

Memory leakages can be checked by monitoring, from time to time, the resources being used as listed by the Windows task manager.

I have done that and no memory leak is indicated. In fact memory usage is quite low.

3. Some sort of power-saving action caused wrongly by something not registering the usage.

4. Some other hardware incompatibility or setting which causes any of the above.

The only power-saving setting i know of is in the Ethernet card/device's properties: find the device in device manager, select its properties and find the "power management" tab, turn off the option for Windows to save power.

There is one hardware setting which can cause problems for some folks. I was reminded of this over the weekend in Lelystad: sometimes the auto-sensing "media type" property on the Ethernet card/device doesn't work so well. Again device manager - properties for the device - "Advanced" tab - then the entry called something like "Mediatype" or "Link speed and duplex" or "speed/duplex settings". It's usually set to "Auto" or "Autosense" or "Auto negotiation" or similar. Try selecting 100 Mbps full duplex instead (both ends).

Okidoki, checking now.

Did you try the UDP protocol? I don't recall. If not, try that. Does it still fail? If so, does it last longer? UDP has less checking and therefore no retries. If the build up and blockage was being caused by failures and retries, then UDP should see less of these, so last longer. If this is the case i'd suspect the hardware, the cable, or some hardware related settings being incorrect.

Haven't tried that. I'm not experienced with this but I will read, learn and do now.

I can't think of anything else. Maybe others can.

Wow, that gave me an instant feeling of proudness being at the same level as you. Very short moment I'm afraid..........

Regards,

Carl

[Dave March]

Carl,

I didn't give you a link

[Pete Dowson]

I just started WideClient without any client applications - just WideClient connected to FS. After 31/2 to 5 minutes WideClient got frozen. This doesen't indicate anything wrong with what you tell; it just tells that there is no que created because of any client application alone.

Does it last longer with no client applications, or just the same? What is the frame rate without any applications? Whether a queue builds up fast or slow would depend on that, not on the application actions per se.

Nevertheless, reading through the server log from the the last try running only WideClient I found this: " 2046327 Error 10054: client socket disconnected at Client: removing (skt=10228) TCP"

Wasn't that at the end, after you terminated WideClient, or when it appeared to freeze?

Haven't tried that. I'm not experienced with this but I will read, learn and do now.

Not much to it. Where you have "Protocol=TCP" in the Client INI, or "PreferredProtocol=TCP" in the Server, change "TCP" to "UDP".

Wow, that gave me an instant feeling of proudness being at the same level as you.

Eras far as Networking in Windows in concerned, I know only as much as most others. In fact less than many. All my Network programming has been standard Microsoft server/client code lifted direct from their examples. And my hardware experience of Networking has been relatively limited simply because it has always worked on all my PCs, right back since Windows 95/98 days. I don't know why it works nor why it doesn't. For me it remains a matter or trial and error. In your position I'd just keep trying things till I found out what it was.

Regards

Pete

[camaflight]

I'm not finnished with the UDP test yet. So many new variables pop up so I have to slow down a little and take fewer things at a time:

Does it last longer with no client applications, or just the same? What is the frame rate without any applications? Whether a queue builds up fast or slow would depend on that, not on the application actions per se.

Not really, the Wide Client log told 357 sec. I never looked at the log regarding this before, just clocked it myself figuring out it was something between 31/2 to 5 minutes. I think we should consider that as the same.

Wasn't that at the end, after you terminated WideClient, or when it appeared to freeze?

Yes it was !

----------------------------------------------

Furthermore - from the server log this was the result:

Throughput maximum achieved: 2 frames/sec, 172 bytes/sec

Throughput average achieved for complete session: 0 frames/sec, 7 bytes/sec

Average receive rate from "KONTORET": 0 frames/sec, 8 bytes/sec

Last time I had 34 frames Max (FS limited to 31), 7 frames min, 11 frames average.

I discovered a new thing: WideClient isn't totally frozen after all. It will be impossible to shut down and it will be impossible to move the WideClient window around at the desktop or restore it when minimized. I discovered this by turning FS off, and then looking at the logs showed that this was registrated as much as it was registrated when I started FS again and once more shut it down. What was impossible though was starting an application - it stated "not connected to FS". The only way to get an application connected for a few minutes again is to reboot the client machine.

So, some questions if I may;

For the network adapter there is an option to set the Speed & Duplex to even 1.000mbps full duplex on both ends. Would that make any difference you think?

When looking in the WideFS technical manual there is a section where some users have made adjustments to exactly the advanced network adapter settings. As I have dual network adapters build into the motherboard this section could absolutly be relevant to me.

However, as stated before; this is stuff I don't understand too much from.

The properties as regards the advanced settings for the one adapter I have in use are with options respectivly as follows: (present settings in bold)

Energy Star -------------------------- Disabled / Enabled

Flow Control--------------------------Tx & Rx Enabled / Disabled

Interrupt Moderation--------------Disabled / Enabled

IPv4 Checksum Offload----------- Disabled / Rx Enabled / Tx & Rx Enabled / Tx Enabled

Jumbo Packet-------------------------1514 Bytes / 4088 Bytes / 9014 Bytes

Large Send Offload (IPv4)---------Disabled / Enabled

Log Status Maessages--------------All Maessages / Errors / None / Status Messages / Warnings

Max IRQ per sec----------------------1000......5000........30000

Network Address--------------------Value / Not Present

Priority & VLAN----------------------Priority & VLAN Disabled / Priority & VLAN Enabled / Priority Enabled / VLAN Enabled

Receive Buffers----------------------256........512

Speed & Duplex----------------------10 Mbps Full Duplex / 10 Mbps Half Duplex / 100 Mbps Full Duplex / 100 Mbps Half Duplex / 1000 Mbps Full Duplex / Auto-Negotiation

TCP Checksum Offload (IPv4)---Disabled / Rx Enabled / Tx & Rx Enabled / Tx Enabled

Transmit Buffers--------------------256........512

UDP Checksum Offload (IPv4)---Disabled / Rx Enabled / Tx & Rx Enabled / Tx Enabled

Wake From Shutdown--------------Off / On

Wake-Up Capabilities--------------Link Change / Magic packet / Magic Packet & Pattern Match / None / Pattern Match

Do you have any idea what should be done here if anything ?

Regards,

Carl

Oh, I forgot something;

Here is a copy of the server ini:

[Config]

Port=8002

AdvertiseService=1

AutoRestart=0

AutoUpdateTime=13

MaximumBlock=4096

NoStoppedRestarts=Yes

Port2=9002

RestartTime=10

SendTimeout=15

TCPcoalesce=No

; -----------------------------------------------

[user]

Log=Errors+

; ===============================================

[ClientNames]

1=xxxxxx

Is this basically OK. I will test the UDP the next thing.

Carl

[Pete Dowson]

Throughput maximum achieved: 2 frames/sec, 172 bytes/sec

Throughput average achieved for complete session: 0 frames/sec, 7 bytes/sec

Average receive rate from "KONTORET": 0 frames/sec, 8 bytes/sec

Last time I had 34 frames Max (FS limited to 31), 7 frames min, 11 frames average.

Yes, but that was with an application, wasn't it? When WideClient doesn't have much to do the exchanges with the Server are simply to maintain contact, so it just sends a frame every so often (a few seconds I think). The max of 2 fps was during the initialisation, exchange of identities etc.

This is why i said that if the problem was to do with buffers or memory leaks it should last a lot longer with no applications. That was the reason for that comparison.

I discovered a new thing: WideClient isn't totally frozen after all.

Well, we knew if wasn't from the original logs i think. It is just that most of the time it is not in control -- something low down in Windows/Network stuff is. That's where it is stalling, or almost -- in fact just going so slow that applications give up..

For the network adapter there is an option to set the Speed & Duplex to even 1.000mbps full duplex on both ends. Would that make any difference you think?

But I already suggested this (well 100 mbps), rather than Auto? Please check back!

Do you have any idea what should be done here if anything ?

No, nothing except what I explicitly suggested you tried!! How did you miss it? Here, I'll quote it again to save to looking all the way back! (Please do read things else I'm wasting my time).

There is one hardware setting which can cause problems for some folks. I was reminded of this over the weekend in Lelystad: sometimes the auto-sensing "media type" property on the Ethernet card/device doesn't work so well. Again device manager - properties for the device - "Advanced" tab - then the entry called something like "Mediatype" or "Link speed and duplex" or "speed/duplex settings". It's usually set to "Auto" or "Autosense" or "Auto negotiation" or similar. Try selecting 100 Mbps full duplex instead (both ends).

Oh, I forgot something;

Here is a copy of the server ini:

Why? You haven't been messing with it, have you? There's nothing you can do in there, except possibly set the preferred protocol.

Pete

[camaflight]

o, nothing except what I explicitly suggested you tried!! How did you miss it? Here, I'll quote it again to save to looking all the way back! (Please do read things else I'm wasting my time).

There is one hardware setting which can cause problems for some folks. I was reminded of this over the weekend in Lelystad: sometimes the auto-sensing "media type" property on the Ethernet card/device doesn't work so well. Again device manager - properties for the device - "Advanced" tab - then the entry called something like "Mediatype" or "Link speed and duplex" or "speed/duplex settings". It's usually set to "Auto" or "Autosense" or "Auto negotiation" or similar. Try selecting 100 Mbps full duplex instead (both ends).

But, I have done so ! - at both ends - as regards speed/duplex settings; set to 100 Mbps full duplex instead.

Please confer:

Speed & Duplex----------------------10 Mbps Full Duplex / 10 Mbps Half Duplex / 100 Mbps Full Duplex / 100 Mbps Half Duplex / 1000 Mbps Full Duplex / Auto-Negotiation

Why? You haven't been messing with it, have you? There's nothing you can do in there, except possibly set the preferred protocol.).

No, of course I haven't been messing with it. The reason I didask was that you told me to try changing the "PreferredProtocol=" from TCP to UDP and I didn,t find that line PreferredProtocol=" in the server ini.

So I just wanted check if there was anything wrong with the server ini I have. That's all.

Regards,

Carl

[Pete Dowson]

But, I have done so ! - at both ends - as regards speed/duplex settings; set to 100 Mbps full duplex instead.

Okayso, did it help?

... you told me to try changing the "PreferredProtocol=" from TCP to UDP and I didn,t find that line PreferredProtocol=" in the server ini.

I a pretty sure I provided both alternatives, to set Protocol=UDP in the Client.INI or to use the 'preferred' parameter (and I don't recall offhand whether it is PreferredProtocol= or ProtocolPreferred=, so you'd need to look it up). Neither are there in the INI files by default, you have to add them if you want them. The Client INI choice forces that protocol for that client (different clients can be operating with different protocols), the Server INI choice is called "preferred" because it merely stipulates the Protocol for any client that doesn't stipulate one itself.

Regards

Pete

[camaflight]

Okayso, did it help?

No.

I a pretty sure I provided both alternatives, to set Protocol=UDP in the Client.INI or to use the 'preferred' parameter (and I don't recall offhand whether it is PreferredProtocol= or ProtocolPreferred=, so you'd need to look it up). Neither are there in the INI files by default, you have to add them if you want them. The Client INI choice forces that protocol for that client (different clients can be operating with different protocols), the Server INI choice is called "preferred" because it merely stipulates the Protocol for any client that doesn't stipulate one itself.

Ok I looked it up; it was "ProtocolPreferred=" not "PreferredProtocol=". It didn't help I'm afraid.

Everything you have suggested I have tried. Unfortunately I have so far no success with my network setup in order to take use of WideFS.

Regards,

Carl

[Pete Dowson]

Everything you have suggested I have tried.

So that includes the power management thing for the ethernet device too?

Unfortunately I have so far no success with my network setup in order to take use of WideFS.

What is weird is that is works for so long then graunches to such a slow pace that applications give up. I cannot imagine anything in software which would do such a thing except the things we tried (memory, buffers, etc). The fact that it's the same with both UDP and TCP tends to eliminate ethernet drivers -- though maybe not fully, as they do have a lot of commonality. You could try IPX -- you'd need to explicitly install the protocol into Windows first, though, and IPX is not quite so easy to configure. Details are provided in the WideFs guides, once you have IPX installed in both PCs. IPX is actually the most efficient and simple Network protocol, having the advantage that it was purposefully designed for local networks, not the Internet. That alone may enable it to bypass some potential problems.

I think hardware problems which do such a slow down are sometimes faulty components which overheat, performing normally till then.

The only other suggestion I can make now is to try posting on the FSX or FS2004 forums here, asking specifically for help from one Katy Pluta. She is the most capable networking expert I know.

Regards

Pete

[camaflight]

So that includes the power management thing for the ethernet device too?

Yes, absolutly all your suggestions have been tried out. Sorry I haven't been quite clear about that I have carried out tests in between. :wink:

I will follow your newest suggestions as well. Before that it would be really interesting to know if there actually is some unsolved or perhaps poorly developed network linkage between Vista Home Premium and XP Pro.

Another option for me is to upgrade to Windows 7 as I receive my W7 shortly. Then I could consider upgrading my old computer with W7 as well (just have to run a feasible test first).

Regards,

Carl