V7
- Thread starter Pthein
- Start date
Shhhh... Let's keep this on the down low until Monday. We are still in progress of posting and getting information out. Feel free to use what you find now but wait until Monday for questions or looking for something you don't find yet. This is a work in progress. Thanks. I rather we not spread the word off this forum until Monday.
Just read through the update instructions and found this slightly worrying note:
“ With the added improvements, it is recommended that users with busy networks and long operational needs restart the software every 10 hours to allow orderly housekeeping of the system software. Failure to restart can result in slower performance and possible unprompted restart after 12 hours of operation”
Was this an issue with the beta version that accidentally remained in the instructions, or is this still a problem?
“ With the added improvements, it is recommended that users with busy networks and long operational needs restart the software every 10 hours to allow orderly housekeeping of the system software. Failure to restart can result in slower performance and possible unprompted restart after 12 hours of operation”
Was this an issue with the beta version that accidentally remained in the instructions, or is this still a problem?
It kind off sounds like a memory leak and maybe it shows sooner on TZT2s as they may have less memory. It may take a lot longer with bigger memory to show. I was hoping that the problem was found in the mean time and the text is a leftover from beta. I think you can’t seriously expect users to restart their systems every 10 hours. I would certainly wait with the update until this is fixed.
Quite possible it’s an old problem showing sooner with less free ram left on the new release. I have one TZT2 permanently on and on average it runs a week or two before it would restart by itself. But it can be much shorter and have the feelIng it has to do errors on ethernet.
I doubt that you can add RAM. It was possible on my 20 year old plotter that had PC type SIMS. But these days it is either soldered to the main board or even integral to the processor.
But it wouldn't really cure the problem of a memory leak, it would just allow you to get away with it longer. I currently think that the restarts I was seeing were related to some kind of error on the ethernet. Depending on the frequency of the error it may run for a day or even a few weeks. I found that it would stop sending out NMEA data over the ethernet, some time before it would restart the same day. I notice because I pick these up on 10021 via UPD and feed it to MaxSea.
Also powering off the radar, shows the expected 'Radar Connection Lost' alarm, but also seems to make it more likely to restart sooner or later.
It is not uncommon for some TCP stacks to 'forget' some resources like packet buffers in case of some unusual error. They restart the protocol but the memory is lost.
But this is of course all speculation and I'm still observing things to more clearly see a pattern. I'm wondering if I should upgrade even knowing about the problem still existing, in order to maybe narrow things down further with a higher frequency of unwanted restarts.
But it wouldn't really cure the problem of a memory leak, it would just allow you to get away with it longer. I currently think that the restarts I was seeing were related to some kind of error on the ethernet. Depending on the frequency of the error it may run for a day or even a few weeks. I found that it would stop sending out NMEA data over the ethernet, some time before it would restart the same day. I notice because I pick these up on 10021 via UPD and feed it to MaxSea.
Also powering off the radar, shows the expected 'Radar Connection Lost' alarm, but also seems to make it more likely to restart sooner or later.
It is not uncommon for some TCP stacks to 'forget' some resources like packet buffers in case of some unusual error. They restart the protocol but the memory is lost.
But this is of course all speculation and I'm still observing things to more clearly see a pattern. I'm wondering if I should upgrade even knowing about the problem still existing, in order to maybe narrow things down further with a higher frequency of unwanted restarts.
To put the comment in perspective, I will provide a little background on the comment in the instructions. There are a lot of changes and new features added with V7. With that Japan told us they found an issue with very busy systems where a unit could see slowdown and reboot after ~12 hours. This only happens with the 12/15. As you might note the note was not in the TZT2BB instructions. This is because the TZT2BB is closer to being a TZT3 than anything. The TZT3 (and TZT2BB) has faster processors and twice the memory of the TZTL12/15F. With that said, memory on the TZTL is tighter and it can not be expanded. Software will still be worked on going forward but being fully transparent we wanted to be honest about how it stands. It all depends on the system but to put it in perspective we installed two units in our lab with two radar, DFF3D, Sirius weather, and Axis cameras. It was well over three days without power cycling before we saw a slow down and never got a reboot. I would call the comment a notice that Furuno is aware of the potential of shortage of memory that might happen under longer term operations on system and advise an orderly restart when convenient as a precaution. The software could have been held up but it was decided the problem is small and with the customer aware it should be allowed to release. I have found v7 to be very robust as most of the beta tester have over the last several months. I wouldn't hesitate to upgrade. v7 offers so much. It makes the TZT2 very much like a TZT3 in operations.
stevemitchell
Member
I used the beta before release, and upgraded to v7 as soon as it came out. I am underway every day and have an extensive NMEA 2000 network. I have 2x TZTL12F units plus a lot of other Furuno stuff + everything else on the network.
I did notice slower response in general using v7 in terms of refreshes, moving around maps, and switching modes/screens, but nothing that makes it unusable. I have seen one reboot while underway which I suspect may have been related to the reason that note was added to the release notes, but one can't be sure.
In general, while I never like seeing things slow down, the integration with v4 of TZ Pro / TZ iBoat and the other nice changes in v7 re: the fonts, reset button for a course at the top of the screen, and other general improvements are worth the upgrade by far to me.
Hopefully over time Japan can throw in a few more optimizations so that a daily reboot is not necessary.
I did notice slower response in general using v7 in terms of refreshes, moving around maps, and switching modes/screens, but nothing that makes it unusable. I have seen one reboot while underway which I suspect may have been related to the reason that note was added to the release notes, but one can't be sure.
In general, while I never like seeing things slow down, the integration with v4 of TZ Pro / TZ iBoat and the other nice changes in v7 re: the fonts, reset button for a course at the top of the screen, and other general improvements are worth the upgrade by far to me.
Hopefully over time Japan can throw in a few more optimizations so that a daily reboot is not necessary.
Successfully updated TZT2BB from V6.26 to V7.01.
But I have a strange problem - the "master" version in the TZT2BB has successfully updated to V7.01, but the "slave" (not very PC - I know) remains at 6.26 and will not update when I put the update flash drive in USB-1.
How do I get it to update to V7.01?
Thanks
But I have a strange problem - the "master" version in the TZT2BB has successfully updated to V7.01, but the "slave" (not very PC - I know) remains at 6.26 and will not update when I put the update flash drive in USB-1.
How do I get it to update to V7.01?
Thanks
A quick update.
I was able to resolve the problem.
The initial update was only partially complete due to - apparently - an incompatible flash drive.
i was using a Sandisk 32GB USB 3.0 drive which always worked to update just the master TZTBB.
Tried a 16GB Sandisk USB 2.0 drive and the update started over and completed correctly for both systems..
I wish that Furuno would either make their USB interface more robust OR provide a list of USB drives that have been tested and "approved".
If there is and I missed it, please let me know.
I was able to resolve the problem.
The initial update was only partially complete due to - apparently - an incompatible flash drive.
i was using a Sandisk 32GB USB 3.0 drive which always worked to update just the master TZTBB.
Tried a 16GB Sandisk USB 2.0 drive and the update started over and completed correctly for both systems..
I wish that Furuno would either make their USB interface more robust OR provide a list of USB drives that have been tested and "approved".
If there is and I missed it, please let me know.
Quitsa
Furuno Super Fan
There is a definitely an issue with certain USB drives not being recognized. I was driven crazy trying to update my DFF-3D because the installer on the TZT 3 did not see the update on the USB drive. I tied three different USB drives and none worked even though all three worked fine on my Macbook laptop and showed the update files in the root directory.
Finally I did what the update instructions say not to do and used a micr0-SD card in a USB adapter as the source of the update. That worked perfectly.
It would help if Furuno made available a list of known USB drives that are fully compatible with the TZT2/3 hardware and software -- or rewrote the unit software if that is the source of the issue.
Finally I did what the update instructions say not to do and used a micr0-SD card in a USB adapter as the source of the update. That worked perfectly.
It would help if Furuno made available a list of known USB drives that are fully compatible with the TZT2/3 hardware and software -- or rewrote the unit software if that is the source of the issue.
Similar threads
