pa1983

I have not been playing KSP a lot the last few years after I quit building space planes. Was a bit hard to find something fun to do motivating me to play but eventually I decided to use KOS and do some scripting. I cant code or script realy so that was interesting After doing some scripts that could take a specific rocket up in orbit or a spaceplane up and land I decided I needed something "Universal". Even with a handful of scripts and rockets when I played career with limited parts one have to invent rockets as the parts are unlocked so realy my new shiny rockets and there scripts where useless until the "end game". So I needed something that worked with most rockets. That is when I started to work on my "Universal Rocket Launch System" or URLS as I like to call it. Its written for KSP 1.2.2 and KOS, I suppose never versions "should work"? You can download the script here. https://dl.dropboxusercontent.com/u/27196441/urls.zip The goal with the scrip is to put ANY payload in a 100-103km Low Kerbal Orbit. Now Im no programmer or scripted, And Im definitely not good at maths so my "formulas" might be a bit strange but they get the job done at least tough there not always as precise as I would like them to be. The script consist of a number of guidance modes. But basically the rockets pitch is calculated and set based on its altitude using a formula I created. The rockets velocity is calculated based of altitude to using a formula I derived and the engines are throttled accordingly to maintain proper acceleration trough the gravity turn. I actually derived my gravity turn formula used for the pitch with a rocket I called the Delta I. It could naturally do a gravity turn so I recorded that data, created a simple script that mimicked that and also tuned the thrust of the stages accordingly. Once I had this simple script I had enough data to create the gravity turn formula I mentioned earlier and the formula for the target velocity and all other formulas I needed. Now the problem is that not every rocket behaves like the one I used as a benchmark, the Delta I. The most common problem I noticed was either a to powerful first stage and a weak second stage and this created a problem. If the second stage is to weak aka low TWR it will not gain altitude fast enough, basically it will fall short of the intended profile of the gravity turn. Since the velocity is calculated based on altitude a second or 3:e stage could actually find it self costing at a pitch up attitude and just run out of fuel since the script did not demand full thrust because the orbital speed at that altitude was meet. As fare as the script was concerned the orbital velocity at that altitude was correct and sure it was but since vertical velocity was around zero the stage would just cost until the fuel ran out. So my next guidance mode I had to create is also based of altitude BUT the formula I derived calculates what time the rocket should be at that altitude. If we assume the rocket turns as programmed by she script and accelerates properly we should always know at what time our rocket should be at a specific altitude. So this secondary guidance mode basically calculates the time the rocket should be at Altitude X and it checks that against the time since launch and if we are ahead or behind to much this guidance mode takes control over the throttle. This mode wont allow the velocity of the rocket to go below 90% of the velocity that was the target, simple reason is that we dont want the rocket to fall out of the sky but other then that it can override the velocity as much as desired to "catch up". This secondary guidance mode will allow even a second or 3:e stage to coast in to orbit. Usually when the second or 3:e stage struggles to get in to orbit its usually enough just to move fuel from that stage to the previous stage, that gives more D/V on previous stage and a lighter second or 3:e stage giving them better TWR. The last guidance mode is basically there to put the rocket in LKO and this mode is activated either when the AP is deemed high enough or the rocket is high enough in orbit. To be able to understand what the script is doing I created a User Interface. It will show useful data the script uses and what guidance modes are in use and what part of the script has completed. This is very useful when designing a rocket to fly with the script. One can pretty easily determine if a stage has the proper TWR or not for example or adjust thrust limits on solid rocket boosters for example since the script has no control over those. I will now explain what the screen shows from top to bottom Apoapsis altitude - this is just apopasis altitude in meters so pretty strait forward Periapsis altitude - this is your periapsis altitude in meters. Vertical speed - this is your rockets vertical speed in m/s so useful to tune thruster limits and engine configurations. Vertical speed target - this is the vertical speed in m/s your rock should travel at the first 1000m after launch. Orbital Velocity - this is the orbital velocity in m/s of your rocket and its used for simplicity from launch to LKO. Velocity deviation - this shows the difference between the calculated velocity and the actual velocity in m/s the rocket is travelling at. Positive number and the rocket is going to fast and a negative number and the rocket is going to slow. Time in flight - this is the time the rocket has been flying since launch shown in seconds only. Deviation from ideal trajectory - this will show you how much behind or ahead in time in seconds the rocket is on its trajectory, ideally you want no deviation but some will eventually occur as the rockets vertical speed declines the accuracy is reduced. Target pitch - this shows the pitch the rocket is suppose to have not what it is, apparently it was very "hard" to script something that would show the rockets actual pitch so you should check this pitch value against the navball to make sure your rocket actually has the authority to pitch over as demanded. Then we have guidance modes. Only one guidance mode can have full authority at a time and what mode has authority will be shown with the word "Active" next to it. Vertical Velocity - This guidance mode is used the first 1000m of the accent, the rocket tries to go strait up and accelerate at a predetermined rate. Orbital Velocity - This is the primary guidance mode for the gravity turn and the one you want to spend most of the time in. It controls the velocity of the rocket according to altitude and should work for any rocket with good enough TWR. Time deviation - this is the secondary or fallback guidance mode. Its primary job is to take control from "Orbital Velocity" guidance mode if the rocket for example has an excessive TWR, like solid rocket boosters that was not properly configured with a thrust limit. Its more commonly activated when a second or 3:e stage has a to low TWR and it will make sure full throttle is used to try and coast the rocket in to orbit. I have also had instances where boosters smashed one of my main engines of and then this mode could save the rocket to. You dont realy want to be in this mode because then your rocket is not balanced to work well with the script but since this guidance mode is based on altitude it will be less accurate at say 50km or higher since the vertical speed decreases and the rockets starts to level of so even the best rockets might spend 10-20 sec in this mode before going in to the last guidance mode. This mode is also triggered if the rocket is 5 seconds behind or ahead of its intended point in time. Orbital Manoeuvrers - this is the last guidance mode and its basically there to get your in to LKO. It is activated either when the rocket has high enough altitude or when the AP is high enough. We dont want the AP to go higher then the intended LKO do we. The last part in our User Interface is Mission parameters. The word complete will be shown next to a mission parameter when it has been executed. Gravity turn - gravity turn is completed. LKO - rocket is in a stable Low Kerbal Orbit. Payload delivery - payload has be deployed. Deorbit burn - the orbital stage has done a retro burn and will now reenter Kerbin at 30km altitude and burn up. Now there area few other things that needs to be mentioned about the script. If an attribute in the User Interface reads "null" the that only means the data is no longer correct or available and therefore no data is shown to confuse the user. The script will check for engine flameouts and will stage as long as there are flamed out engines. The script will also check for active engines and stage until active engines are detected. Every time the rocket stage it will default to full thrust on the engines just to make sure it wont fall behind on its intended trajectory since the TWR will usually be lower with a new stage then an empty one. The scrip uses action group 10 to jettison faring or anything else you want to get rid of, this will happen at 54000m. If you want to jettison your faring earlier you can have that in your staging sequence as usual. The reason I opted for 54000m to jettison fairings is the the fact that I got destructive wobble with 3.75m parts up to about 50000m. Since the script is universal I need a safe altitude to deploy the fairings. The script will stage one last time in orbit to jettison then payload, but action group 9 is also triggered and can be used to separate a payload from the last stage and also extend antennas if you need an uplink to control the payload. Also the scripts formula to estimate velocity is a bit off in the early part of the gravity turn compared to the rocket it was designed for (Delta I) so its pretty common for it to report that the rocket is a bit behind in velocity but still show that the rocket is on time aka no Time Deviation. Try out the Delta II rocket supplied with the script for a good benchmark rocket to use as a reference. For the first stage I usually use a TWR of 1.5 based of the Vacuum numbers, if I use the atmospheric numbers I tend to go with 1.3. The scrip is primarily intended to make launches easy and routine and not to make them the most efficient to save that little bit of fuel. You should tune your rocket so it spends most time in the "orbital velocity" guidance mode for best performance but the script is intended to fly pretty much anything that can be flown manually tough its not designed for space shuttles. I have tested pretty much all my rockets, good and bad once and also most stock rockets in KSP and they do work (staging order might need tuning tough). You can download the script here. https://dl.dropboxusercontent.com/u/27196441/urls.zip It will include the Delta II rocket (improved version of the Delta I but performance the same) and also a Soyuz ST (picture below) that I designed using the script. I would recommend flying them first to get an idea of how the script works and how you can use it to tune your rockets. So now its up to you to break my script and tell me what it cant do So feel free to post any good or bad launches in this thread.

Firmware patch is coming the 15th October at the earliest samsung sees. http://www.nordichardware.se/SSD/HDD/prestandaproblemen-i-samsung-840-och-840-evo-korrigeras-i-firmware-uppdatering.html http://www.golem.de/news/samsung-ssd-firmware-fuer-840-evo-gegen-tempoverlust-kommt-mitte-oktober-1409-109434.html http://www.sweclockers.com/nyhet/19375-samsung-lovar-atgarda-prestandaproblem-i-840-serien-ssd-med-ny-firmware

No samsung realy wants to keep a lid on things as much as they can. Never samsung again for that reason. Customer support is just terible. It was good before I think. When I got a bad LCD monitor 5 years ago or something they sent a brand new one out ASAP after a phone call. But the new 3:e party support that dont have any contact with samsung just sucks so much. The retailers I spoken with confirms that the end user has no chance realy with there support nowdays. They are to big on retailer told me. The fact that people like me and hundred of others have made us heard eventually triggered tech sites to write about it. Nordichardware thanked me for the brining it up and helping them best I could collecting more data for there article. But it sad that it took almost 2 months before samsung responded to the uproar from frustrated users. Never Samsung Again! Sweclockers responded to one of my e-mails but never none of the later once with anandtechs article etc. But they wrote an article finally about it. its like 200K swedish users in there forum so. Any news there gets attention. http://www.sweclockers.com/nyhet/19362-samsung-840-och-840-evo-ssd-lider-av-prestandaproblem

Nordichardware.se wrote an article. Have have had email contact with them the past two weeks. Its in swedish but google translate should work. http://www.nordichardware.se/SSD-Recensioner/sa-kringar-du-prestandaproblemen-i-samsung-840-och-840-evo.html

Samsung acknowledges the problem and is working on a firmware fix. No ETA but this is progress. At least they can be held responsible now sense they admit to the problem. http://www.anandtech.com/show/8550/samsung-acknowledges-the-ssd-840-evo-read-performance-bug-fix-is-on-the-way

Well I ended up ordering replacement Crucial MX100 for all effected systems I built. Anandtechs wrote in there comments to the new sandisk SLC drive that they have information they will reveal in a few days about the 840 /840 EVO bug so I would stay tunned to that web page the next few days and see what happens.

Yes its good to show other models are not effected.

830 and 840PRO uses MLC NAND and are not effected as fare as we know.

Yea for now. Sadly wont last forever. interesting to see another 840 effected tough since the 840 EVO gets the most attention.

Well only a fraction of users would know about the problem and fewer would user a fix. In the end I dont think its viable option. I will clam manufacturer fault here in Sweden either its covered by samsung or not here in Sweden any product with a proven manufacturing fault you can send back for a replacement. And if they cant fix it well then they have to refund you. And I already spoken with one of my resellers and with the amount off evidence it should not be a issue they told me. All they wanted are links to threads to confirm that more people are effected then by law they are obligated to help me. And if samsung wont release a fix I can skip the howl replacement product step the law allows the reseller to take if its a possibility. Theres no way a reseller can fix a broken SSD.

Yes people tested that. People that wants to know more should read trough the overclock.net thread. They are implementing such fuctions in those test programs to do just that. But rewriting data restores performance. So if you have some way of doing that it should work as a temporary fix. But expect the problem to return in a few months. This is also the reason I think Samsung could make a fix like that part of ware leveling. Either move data after X amount of time or do a read the of LBA's sequentially at idle and rewrite any slow data. If the degradation happens after average 2 months that would mean it cost you 6 PE cycles per cell a year assuming the cells have data stored so a small fraction of the 1000 PE cycles per cell would be used every year.

As fare as I have seen the degradation ONLY happens in cells containing data so yea you wont see this on a new or unused 840 or 840 EVO. So where the SSD is fast is where it has not stored data or stored data recently. Windows users can use this program on there own risk. It will read actuall files and tell you how fast they read and how old they are. A user wrote it over at overclockers.net so us it on your own risk. I used it on the 840 500GB with no problems tough. https://dl.dropboxusercontent.com/u/27196441/840/SSDReadSpeedTester1.00.zip Results will look something like this if your files reads slower the older they are. Linux users can use this script. https://dl.dropboxusercontent.com/u/27196441/840/SSD840bench.sh Just add the dir after the script you wish to test. Root is not required. If your drive is effected the best forum so fare seems to be over at overclockers.net. Link to the thread is in my first post. Registering is easy there. The UK forum denied my registration. Probably because its connected to a store and they want UK users only. The sad thing is that pretty much every one that has tested there drives after being informed of the issue have had the fault. I have seen users that tested multiple 840 EVO being so sure the next on they test will have it they are willing to bet there lives on it more or less. So the issue seems to effect every TLC samsung model so fare with very few exceptions. New drives usually dont showt he problem until 2-3 months with static data on the.

I also know its less durable etc. Its not realy the users concern if Samsung messed up the reliability of TLC NAND if the user celected a SSD that has a life span that fits the users needs. On all our systems we will never hit the advertised write limit. Also only one system can fully exploit the performance due to sata 6Gbit, the rest are stuck on 3Gbit and are basically boot drives for Linux and some basic services. Back when Gen1 and 2 SSD's where out static life span of data was some times in the specs. if I recall 10 years where not uncommon for SLC and MLC drives back then. The basics of NAND is that SLC uses two voltage states to reprecent 0 an 1. MLC represents it with 4 states to encode 00, 01, 10, 11. TLC needs 8 states to encode 000 to 111. The controller basically programs the cell with a voltage it knows represents a series of bits. Problem is if you try to store 3bits with 8 states in a 3V range the margin is half compared to MLC with 4 states and a 3V range. If I recall teh 840 EVO programs it cells with 15-18V so the 8 states needs to fit in there. So that means the controller need to write very accurate voltage level but also be able to read it back later and determent what bits the voltage represent on the fly. To me the later seems to be the problem. The TLC might just be degrading so fast that ECC has to kick in. If I recall anandtech wrote that TLC used 24bit ECC and MLC 15bit ECC. Couple that with MLC being more proved and should take a lot longer to degrade where it would cause problems for the controller this might explain the slow read performance on 840 EVO afte a few months. Also even if the TLC is at fault a firmware should be able to refresh cells making the Tech more viable. For light use, typical desktop or boot drive even if the TLC drive shuffled the static data around every so often it might cost 6-12 PE cycles on a 100% full drive etch year. Not a big cost I say with 1000 PE cycles. From my small sample size and from what I see the 840 seems to degrade slower so I suspect the 21nm TLC NAND dont degrade as fast as the 19nm NAND in the EVO but thats just speculations. Need more drives to be sure of that. My 840 only degrades to EVO speeds after 11 months instead of 3 months so. That theory would to some part explain why we only see 840 owners reporting the fault at a limited number unlike 840 EVO owners and also why 840 owners reports it now and not before to a bigger extent. I my self is no fan of TLC BUT Samsung good reputation, Sandforce 2 bad reputation, OCZ being junk the 840 and 840 EVO seemed like good enough for many people and the reviews where good to. In my primary rig I run a MLC Crucial M4 SSD. Also in my HTPC i use an Intel 320. But if it was not for this degradation of the read speed on the 840 and 840 EVO I cant see what use MLC or SLC would do in a system that makes very few writes a year and hardly requires the performance of high end SSD's. SSD for me in my router and NAS is just to keep noise down, power use and save space instead of having an old HDD hosting the OS. The cost between a low end SSD and a low end HDD is not that big.

I know the differens between SLC, MLC and TLC. NAND. In practice its just a question of the number of voltage states used during programing. The 840 EVI uses15-18V to reprisent 8 states, 3bits. But the 840 EVO also uses the TLC NAND in SLC mode for faster writes called torbowrite. Just uses some dedicated TLC NAND for that. The MX100 is considered better since it has MLC NAND. But NAND is NAND, not realy that much of a difference. Problem is that the more bits you reprecent the smaller the margines on the voltage used for programing. NAND cant keep data for ever ither. What samsung saves is not cost per chip but they can use fewer chips for the same amount of storage. The 840 500GB has less then 300h on it after 1.5 years. Used for surfing and storing photos. At the time 500GB MLC was way to much and even TLC whit less PE cycles would last longer then the machine. So no reason for a expensive MLC SSD at the time. My linux router uses the EVO, it sees 10-100MB written to it a day I would say. I could never use all the PE cycles even on a TLC SSD.

Well due to the nature of how SSD's works you might not notice it at first. An SSD even at 50MB/sec and access times in the low 0.2ms will still feel faster then a hard drive especially at random access. But people have noticed slow downs in daily use. Depends very much on how heavy your use scenario is. People that do daily backups have noticed a big increase in time it takes for the scheduled backup to complete. Any way I hop the information was helpful to some one.