Problem with PM LNAV and VNAV possible network issue?

[raflyer]

Hello,

While using PM software, LNAV and VNAV cease to function after initial turn-on. Jonathan, after looking at my logs, thinks it's a widefs/network problem. I have the logs and ini file if you need to see them. It looks like wideserver is having trouble with data transfer to the CDU computer(flightsim4) I have 4 computers networked together thru a 100mb switch. Normal winXP functions ok, by that i mean, i can access the files from flightsim4 computer just fine. Seems to only have trouble while running fs9? I'm at a loss here since it worked fine for over 500hrs of operation. For the life of me i can't remember if i changed something or what. Where do i send the files pete so that you may view them?

Thanks,

Rob

[Pete Dowson]

While using PM software, LNAV and VNAV cease to function after initial turn-on. Jonathan, after looking at my logs, thinks it's a widefs/network problem.

Odd for him to say that -- if WideFS was having problems it would affect everything, not just selectively VNAV and LNAV operation. It has no idea what data is being transferred. When using PM there will be data flying about all over -- why does he think it would be selective?

I'm at a loss here since it worked fine for over 500hrs of operation. For the life of me i can't remember if i changed something or what.

That is a bit of a problem isn't itbacktracking is a useful way of working things out.

Where do i send the files pete so that you may view them?

ZIP them together and use the "email" button at the bottom of my messages.

Regards,

Pete

[Pete Dowson]

From your private message:

After takeoff, the CDU which is by it'self on Flightsim4 computer, fails to respond or becomes very slow. If i change a route waypoint, before i execute it, there should be a white dashed line pop up on the pilots pfd. This doesn't happen unless i wait for a long time. I think this is why i have a problem with lnav and vnav since it is pm generated autopilot function which relies on the cdu for proper function. For some reason, everything works fine till after takeoff??

The logs don't actually show a lot wrong -- something serious, though, certainly. Your CDU PC was evidently ready and waiting to connect for a long time (2268 seconds) before FS was loaded and ready on the Server. Really after that there was only one error detected at that end:

2580260 Note: Send() request depth is over 100!

which occurred 293 seconds later. This problem indicates some blockage at the Server end, possible you were in a menu or doing something else in FS other than flying? Or, more likely, this is coincident with the problems shown in the Server Log (below). However, because everything evidently starts at wildly different times it is difficult to tie together. And you didn't close the CDU client before Zipping up the Log, so I can't see the performance analysis at the end.

In the Client INI file there's nothing wrong, though you could probably run PM's CDU okay with Timeout=0 set. It would give it a little more time, especially as there's nothing else running on that PC.

In the Server end, these errors are bad. You shouldn't get many if any of these:

702687 Retried 314 times: sends blocked for over 5 secs! (0 of 337 sent), Error=10035 (skt=8880)

707703 Retried 620 times: sends blocked for over 5 secs! (0 of 348 sent), Error=10035 (skt=8880)

708844 Send ok but needed 693 attempts! (370 of 370 sent) (skt=8880)

712234 Send ok but needed 75 attempts! (353 of 353 sent) (skt=8880)

716375 Send ok but needed 86 attempts! (333 of 333 sent) (skt=8880)

719734 Send ok but needed 65 attempts! (367 of 367 sent) (skt=8880)

723609 Send ok but needed 59 attempts! (329 of 329 sent) (skt=8880)

726875 Send ok but needed 55 attempts! (336 of 336 sent) (skt=8880)

730703 Send ok but needed 38 attempts! (330 of 330 sent) (skt=8880)

739891 Send ok but needed 6 attempts! (311 of 311 sent) (skt=8880)

743500 Send ok but needed 15 attempts! (308 of 308 sent) (skt=8880)

746406 Send ok but needed 27 attempts! (346 of 346 sent) (skt=8880)

750266 Send ok but needed 59 attempts! (339 of 339 sent) (skt=8880)

753656 Send ok but needed 68 attempts! (337 of 337 sent) (skt=8880)

758000 Send ok but needed 85 attempts! (349 of 349 sent) (skt=8880)

761328 Send ok but needed 57 attempts! (333 of 333 sent) (skt=8880)

765328 Send ok but needed 71 attempts! (333 of 333 sent) (skt=8880)

768391 Send ok but needed 35 attempts! (332 of 332 sent) (skt=8880)

772062 Send ok but needed 32 attempts! (337 of 337 sent) (skt=8880)

774922 Send ok but needed 26 attempts! (343 of 343 sent) (skt=8880)

778500 Send ok but needed 44 attempts! (338 of 338 sent) (skt=8880)

781375 Send ok but needed 42 attempts! (329 of 329 sent) (skt=8880)

785062 Send ok but needed 48 attempts! (342 of 342 sent) (skt=8880)

787984 Send ok but needed 27 attempts! (344 of 344 sent) (skt=8880)

791828 Send ok but needed 45 attempts! (337 of 337 sent) (skt=8880)

794859 Send ok but needed 30 attempts! (327 of 327 sent) (skt=8880)

798453 Send ok but needed 10 attempts! (283 of 283 sent) (skt=8880)

818766 Send ok but needed 28 attempts! (308 of 308 sent) (skt=8880)

822234 Send ok but needed 30 attempts! (302 of 302 sent) (skt=8880)

826641 Send ok but needed 43 attempts! (320 of 320 sent) (skt=8880)

All the above occurred in a period of just 2 minutes!

Interestingly larger gap here, no problems for 3 minutes 37 secs!

1041547 Send ok but needed 18 attempts! (309 of 309 sent) (skt=8880)

1045156 Send ok but needed 19 attempts! (307 of 307 sent) (skt=8880)

1049328 Send ok but needed 30 attempts! (291 of 291 sent) (skt=8880)

1064891 Send ok but needed 7 attempts! (171 of 171 sent) (skt=8880)

1068953 Send ok but needed 31 attempts! (276 of 276 sent) (skt=8880)

1073516 Send ok but needed 21 attempts! (276 of 276 sent) (skt=8880)

1077531 Send ok but needed 23 attempts! (250 of 250 sent) (skt=8880)

1082453 Send ok but needed 51 attempts! (289 of 289 sent) (skt=8880)

1086719 Send ok but needed 49 attempts! (285 of 285 sent) (skt=8880)

1091703 Send ok but needed 62 attempts! (294 of 294 sent) (skt=8880)

1096094 Send ok but needed 61 attempts! (312 of 312 sent) (skt=8880)

1101266 Send ok but needed 69 attempts! (303 of 303 sent) (skt=8880)

1105766 Send ok but needed 71 attempts! (316 of 316 sent) (skt=8880)

1110875 Send ok but needed 72 attempts! (270 of 270 sent) (skt=8880)

1140781 Send ok but needed 35 attempts! (260 of 260 sent) (skt=8880)

1149016 Retried 321 times: sends blocked for over 5 secs! (0 of 321 sent), Error=10035 (skt=8880)

1149297 Send ok but needed 339 attempts! (319 of 319 sent) (skt=8880)

1154766 Send ok but needed 79 attempts! (307 of 307 sent) (skt=8880)

1159094 Send ok but needed 79 attempts! (293 of 293 sent) (skt=8880)

1164812 Send ok but needed 82 attempts! (278 of 278 sent) (skt=8880)

1201187 Send ok but needed 94 attempts! (287 of 287 sent) (skt=8880)

The only error being reported here is that Windows is saying it cannot send the frame because it would be "blocked" (i.e. cause FS to stop awaiting the frame to be transmitted). I cannot allow that, so I count the problem and retry later -- as you can see, eventually it is transmitting but it is taking many retries each time.

The only times I have seen this sort of error is when there is something actually wrong, but what that would be, I'm sorry I don't know.

In your message you explain that the PM CDU is getting intpo a slow update situation. I think the sorts of things you are talking about happening on the CDU are not actually done through WideFS, they are file system accesses using Windows sharing. It looks like, whatever the CDU is doing, it is somehow conspiring either with or against WideFS to block that route.

Sorry. I think maybe someone like Katy Pluta is needed here, to try to resolve why the Network is having these difficulties. I don't know enough about networks to have any other suggestions -- though please set Timeout=0 as suggested above, in case that helps a wee bit.

One thing, though. In your WideServer.INI file you have:

AutoUpdateTime=15

RestartTime=10

The default for the Auto Update, of 13, was arrived at after lots of experiments and I think you should stick to that unless you have good reason to change it. I would certainly never use a larger value than the default.

For reasons recently discovered, please for now set the RestartTime to 0, or maybe 30. In the next version of WideFS you can leave it to default. I can't see any sign in the logs that this had any affect on things though.

Regards,

Pete

[raflyer]

Thanks Pete, i'll give that a shot. I do agree that something is happening in the network. Just not sure why it starts after takeoff?

Rob

[Pete Dowson]

Thanks Pete, i'll give that a shot. I do agree that something is happening in the network. Just not sure why it starts after takeoff?

Rob

I suppose PM's not talking much before then.

Regards,

Pete