*) queue - added bucket-size setting to queues (derived from max-limit);
*) queue - improve “/queue interface” menu;
What does it mean???
I had updated a test device, but it uses no queues. What is the difference to older versions?
i see on the queue interface all interfaces/bridges get an “no-queue”
any information about that?
I think its better to have bucket-size value in kb, just like in squid delay pool.
It is radio to max-limit (0,1 is 10%)
HTB (Hierarchical Token Bucket) is finally getting custom size buckets 
https://en.wikipedia.org/wiki/Token_bucket
basically this option can eliminate any need for bursts options, and allow much more neat hierarchical structures.
I do not understand how it will work if bucket size is 0 .
Simple burst behavior can be achieved by use values more that 1. For example if you set bucket-size=4 max-limit=10M - first 40Mb will cross the queue with virtually unlimited speed.
I plan to use this analogy when explainig it in future:
05-animal-driven-waterwheels-are-known-in-murcia-as-norias-de-sangre.jpg
bucket size determines amount of delivered water ( traffic) per take, you cannot control the amount of water in the bucket (it always come full), but you can control number of buckets per second, bigger buckets = smaller number of buckets per second = more burstness of the traffic (and i would imagine less load on CPU)
No way to upgrade 741TC from 6.35rc8 to 6.35.rc11 because of “low memory”
741TC.PNG
Edit the queue on this interface. I had the issue with my openvpn connections
! No band g/n Option !!!
1.png
2.png
3.png
BartoszP - Upgrade in this device happens within RAM memory;
PeterDoBrasil - For now it is available only through CLI.
You must be kidding.
Bartoszp, install system package only, reboot. You will get space and then install only additional packages you need in second stage. After that you will have enough space for future updates. At least so far…
The lacking of ram and flash capacity in new models is awful.
Is RAM upgrade maybe also coming to CCR devices?
The reason I’m asking is that for some reason, RouterOS for tile is HUGE when installed (46 MiB used out of 128 MiB on a CCR1016-12S-1S+), which makes using partitions almost impossible now (barely enough space to perform upgrade when using 2 partitions at 64 MiB each). CCRs have plenty of RAM, but it can’t be used for upgrades. Why is installed size on CCRs so large? The .npk is smaller than the powerpc version, but when installed ROS is twice the size!
For that reason I am currently not using partitions on CCR1016s even though I would like to, because i am afraid that with future ROS versions, install/package size will grow even more until I finally run out of space 
If you compare, ROS 6.1 npk for tile had around 14,2 MiB size, ROS 6.32.4 already has 16,5 MiB, and with more and more features being added, the size will probably not get any smaller in the future.
It is explained here:
http://wiki.mikrotik.com/wiki/Manual:System/File
Warning: If device has a directory named “flash” in its file list, then files which you want to be kept after system reboot/power cycle must be stored within it. As anything outside of it is kept within a RAM disk and will be lost upon reboot. Note: this does not include .npk upgrade files as they will be applied by upgrade process before system discards the RAM drive content.
Kidding or not, misinformation or not, your suggested method has not worked for me.
While jarda’s worked just fine.
So is it misinformation when your method is not working properly?
The bottom line is that using jarda’s method I did my job. So fix your software if you don’t want ‘misinformation’ going around.
Most likely you just rebooted device which erased RAM memory and after reboot you had enough space for upgrade.
Version 6.34.2 has been released:
http://forum.mikrotik.com/t/v6-34-2-current-is-released/95555/1
http://forum.mikrotik.com/t/v6-35rc-release-candidate-is-released-new-wireless-package/94918/94
The device on that screenshot was just rebooted. Since it’s with an rc version it was used for testing and not in production.
Thus no ram was used since no special config was done on the device.
So, since I’ve been doing it wrong for the last 10 years using Mikrotik, what should have been the proper way to upgrade the hAP without resorting to not using the combined package as Jarda suggested (and worked right away) ?
Again - Warning: If device has a directory named “flash”…
Upgrade happens like this only with devices which has flash memory. I guess we have such devices for about a year now.
Do you have actual screen shot where you could see that free RAM memory > necessary memory for upgrade?
No but I know that the free memory was ~11mbyte.
Yeah, what about it?
I don’t want to store files. I want to upgrade. From what you are saying upgrades happen in RAM. So what does it matter weather there is a flash folder or not?
In general SMIPS is a disaster in terms of usability.
It forces us to use Winbox 3 which is super buggy and it cannot upgrade like every other device model you make…
What means CLI??? I don’t understand what is CLI???
CLI means “Command line Interface”, when you connect with SSH for example
Cha0s - About upgrade - my mistake. Every device which has flash memory (except SMIPS) performs upgrade within RAM memory. hAP lite has flash storage but does not have flash folder so upgrade happens within flash directory. Sorry about that. Upgrade bundle + other package is not possible because there is not enough space for it. .
If you have other SMIPS and Winbox related issues, then please report to support@mikrotik.com. We are not aware about still existing issues with SMIPS or Winbox which would break workflow.