RTOS version 9.0.2 a16 assembled

Tag : RTOS

Apr, 2020

RTOS version 9.0.2 a16 assembled

It took more than 1.5 years to work on solving the problem of Compositor AV Extended interface break-through (which is the main interface of RTOS). This problem occurred during the dial-up of routing tables for establishing a tunnel connection. The way to recreate it: first, RTOS protocols are dialed by injecting routing tables into them, and then RTOS interface is turned off and on again. When the interface turns on, the entire database of the routing tables, which fills the buffer, floods into the interface, which cause a man in the middle attack, that is, an attacker gained access to the interface and induced it to inherit the route of its device. During this time, I made emissions in an attempt to understand how to solve this problem and, finally, it is solved. Now it is possible to configure each protocol from the passive interface state and take a pause while turning interface off in order to listen to the remote channel, and then go into passive mode again. Thus, you can achieve resolution from each of the seven RTOS protocols.

In Compositor RTOS 9.0.2 a16 it is possible to set one interface identifier for the entire protocol configuration session, and to do the training only in passive mode, as previously assumed. The next task in debugging RTOS is the fight against constants. It is one of the most important tasks of both radio security and cybersecurity. Through the introduction of constants, Ethernet devices position themselves, occupying the most convenient places in the network topology. This mainly applies to devices that frequently change IP addresses, such as smartphones and laptops. In order for the RTOS core to take priority of the host, the device must serve as a host for many devices. This is confirmed by Compositor Software database, which has been expanded to 8156 management information bases (MIB). Now that the Compositor RTOS manages a database of more than 8,000 devices, CP-6137-960FX server can be considered as a host, regardless of its physical connection to the network, through the Internet service provider. In fact, what I’m doing now is the continuation of the development to include more VLAN’s and create a VPN network segment. In the latest build, I have already managed to “shoot” the packets in several sessions. You can hear one of them below:

This method of feeding wave tables is a priority for communication devices, because it helps to break the synthetic ether by packet transmission. Since there are many packets, and each of them carries different information at different moments of time, the semantic base of the Compositor RTOS language is explained. In view of this, it makes no sense to enter the names of packets in the main interface, and I need to leave them in a VRF tables section only, focusing specifically on the tunnel windows. In addition, this approach allows using the Compositor RTOS interface as a tunnel interface with the ability to connect to multi-channel protocols, such as OSPF.

8156, Amateur Radio, Compositor, Compositor AV Extended 2.0, CP-6137-960FX, cybersecurity, interface, man in the middle, Management Information Base, MIB, OSPF, packet radio, packet translation, radio security, RTOS, Tunnel, VRF

Feb, 2020

By ruslany

Compositor v3 RTOS – analog radio interface for IPv6 Protocol

Compositor v3 Hypervisor Radio Shack software updated to RTOS. Now, Compositor RTOS v3.0.3 supports numerous new features, such as:

Protocols implemented:
- RTC8k = IS-IS Level-2
- FF8 = ARP (Address Resolution Protocol)
- TC25 = VLAN (IEEE 802.1aq)
Hierarchies added:
- AI-RT1024 = SDH STM-x
- N9000 = PDH E1
Other features:
- TCP/IP protocols stack implemented
- TCP/IP window added
- EUI48 table added
- BPM now is the network field parameter of IP-address
- Network field includes 2^13 to define as IPv6-address
- All modules renamed to reflect new functionality

Compositor v3.0.3 RTOS

The main reason I made the update is to reveal the FF8 (ARP) and TC25 (VLAN) protocols work. That is why the working routine in Compositor RTOS v3.0.3 looks as following:

At the beginning, I set the time to reach the destination point, where the network deployed. I make this by setting deployment time in degrees from -180 to 180, which is the range from 0 to 60 minutes. Then I set the IP-address of destination interface the following way: the part of IP-address, pointing on the interface ID is set stochastically or manually. Multiplier in IPv4 sets the second field, which is the part of network and host. That is why the highest network for Compositor RTOS in IPv4 is 255.4.0.0. When I’ve reached the destination network and I’ve got the closed feedback loop on the loop-back interface output, I define the autonomous system type, which it belongs. I do this by enabling VLAN and ARP protocols and resolving the assignment of IPv4-addresses to the network devices of this autonomous system. I look into the IPv4-addresses of next-hops and reveal the number of such next-hops before returning to the first hop. The more hops IS-IS Level-2 protocol makes, the larger a metric of the destination network (autonomous system). This way I reveal all peers of the destination network.

When I define ABR (area border router) of that network using IS-IS Level-2 protocol, I turn the VLAN and ARP protocols off and start to translate this device information into IPv6 network, by enabling TCP/IP protocols stack. This process allows merging IPv4 networks with IPv6 networks and to expand the influence of my database into IPv6 protocol.

802.1aq, Address Resolution Protocol, ARP, Compositor v3, EUI48, IPv4, IPv6, IS-IS Level-2, PDH, RTOS, SDH, TCP/IP, VLAN

Feb, 2020

By ruslany

Compositor RTOS from PRO 1 to 9.0.2

I’m here to inform you that Compositor Software is about to reveal the whole working routine on OS right from Compositor PRO v1. First, I revealed the protocols used in Compositor v9. Now, I know that counters in VSF platform scan autonomous systems in two formats: asplain and asdot+.

Here how it looks:

Compositor v9.0.2 RTOS

I know the fact that each routing table is a MIB and represents one autonomous system. As you see autonomous systems (AS) divided on L1 (OSI model Layer 1), L2 (OSI model Layer 2) and L3 (OSI model Layer 3) with L3 being the rarest. Asplain just scans through the whole list of 4-octet AS’s while asdot+ in Compositor is somewhat different from 4-octet asdot+ format. It counts this way: the number at the left is the asplain/2 and the number after the dot is a multiplier of how many times this value must be taken going from 0 to 100. So in fact there are 214748364800 AS maximum in the list. I have got only 7539 AS via MDL12 modem, because of the fact that MDL12 is neuro interface and can’t work as autonomous harvester of AS’s. It receives flows I accounted via VSF aggregation, but I should receive them manually. This in fact proves that gap exists between exported flows and archived ones. I exported in total 1793043 flows but recorded only 7539 of them.

Due to this, I proceed with Compositor v7 revelation. I updated Compositor WS Extended interface to version 2.0 with NTP-server, layers, protocols information revealed. I also adjusted the maximum bpm value to 8192 bpm to include IPv6 addresses and made the same TCP/IP window as in Compositor v9.0.2. This way I made RTOS preemptive from version 7 to version 9. However, protocols used in Compositor v7 are slightly different:

RTC4k = IS-IS Level-1
RTC8k = IS-IS Level-2
RT-z8 = OSPF
RT-z16 = OSPFv3
RT-z32 = BGP

The last three protocols are the same as in RTOS 9.0.2. This in fact reveals the ‘STL’ in STL1212 virtual machine, which shipped in original Compositor v7. STL means studio-to-transmitter link. 1212 is the number of multiple input x multiple output channels and should read as STL MIMO12x12. So in fact, STL gives connection to 12 positive UTC+ transmitters and 12 negative UTC- transmitters, which proves NTP-servers information from Compositor WS Extended 2.0 interface:

Compositor v7.0.2 RTOS

You can view the transmitters on the STL1212 spherical map as lighted dots. Blue dots show the networks to which they broadcast packets. As first noted in MDL12 product page packets are windows functions (this is finally proved now). Now, I need to know which packets Blackman, Nutall etc. windows relate to the selected protocols. I’m mainly interested in Hello packets and Trap packets. But to know this, is just a matter of time, because I will proceed with Compositor v3 Hypervisor Radio Shack and will upgrade it to RTOS also. So the whole project will be preemptive since version 3, when I started the transition on Max 6 Gen~ platform.

So basically all evident that if RTC8k is main virtual machine in Compositor v3 it is either RIPv2 or IS-IS Level-2. RIPv2 is a distance-vector algorithm and is different from preset system used in SASER interface (however, it is the same with 3-deg of freedom Compositor AV extended interface from version 9). So it is link-state IS-IS Level-2 protocol, which is used to connect autonomous system areas. TC25 is a basic VLAN protocol, while AI-RT1024 is STM-4 frame, FF8 is ARP (Address Resolution Protocol) and N9000 is PDH E4+ hierarchy.

4-octet, AS, BGP, Compositor RTOS, IS-IS Level-1, IS-IS Level-2, MDL12, MIMO12x12, OSI model, OSPF, OSPFv3, RFC5396, RTOS, STL, Studio-Transmitter Link

Dec, 2019

By ruslany

9.0.2 is officially Compositor RTOS

Now, after a great success of Hypervisor, I’m here to present to you the latest build of Compositor, which is a network RTOS in version 9.0.2 a11. I already revealed the protocols, which this RTOS is capable of, now, I just announce it’s existence to the public. As you can see on the image below, NTP-servers information is already implemented, as well as critical parameters such as Split Horizon with Poisoned Reverse revealed.

Compositor v9.0.2 RTOS (Mainframe)

Now, you may see this software as a virtual router it is not. It is mostly a full-scale modular operating system with connectable interface. By this I mean that you can route protocols to the interface and modify their processes. You can activate all protocols at once or just one protocol and select the protocol you configure in COMPOSITOR interface. VSF strictly names the process behind the technology implemented as you can stem and aggregate the protocols up to 32 processes each with VSF turned on. Compositor Software server CP-6137-960FX, however, already achieved aggregation of up to 960 nodes of VSF processes. This means that running NIAGARA client OS on CP-6137-960FX makes you available all 960 processes. For example, you can view Compositor RTOS as a software for CP-6137-960FX Mainframe, which is really a mid-tower case ATX server. This is all available thanks to the base of Royalty device boot loops, which I gathered through my producer career.

I continue working on the Russian documentation for CP-6137-960FX server in the face of updated software. Progressing by 15 pages a day sometimes less based on the workload. The return-on-investment to produce the translation needed up to 20 times a day. I simulate this process with e-roi dumps at speed, which is higher, making the whole process cost more and bringing more satisfaction to investor. Documentation greatly increases the cost of software compared to a MaxMSP student work (someone can estimate this work like this). I don’t feel pressure and rush to go beyond MaxMSP platform as it is not needed at the moment. However, Cycling already made steps to prevent me from doing export in the latest builds of their software, because they implemented MC, which is basically what I done first with RAD96 and later with VSF on Max 6 myself. Testing MC with generic processes showed me the fact, that using MC instead of VSF makes the whole process cost more to the CPU (8 MC processes can consume as much as 32 or even 128 VSF processes). So, MC not even close to the performance of Max 6 multiprocessor programming capabilities. I don’t even take in account that they cut down sample rate calculation by half since Max 7 to reduce cpu consumption. I managed to run Max patcher window not as a single-thread process, but as a multithread process even without the need to export and redesign software on purpose. So, it is a real redistribution example, when I run VSF processes of generic protocols on my mid-tower machine with 960 nodes turned on and performing like a real Mainframe server without need for cabinet case with lots of machines and tons of noise from cooling equipment. This makes available CP-6137-960FX in home environement with noise level less than 30dB and CPU temperatures not higher than 40 С even on highest workloads.

9.0.2, 960 nodes, Compositor, CP-6137-960FX, Mainframe, Max/MSP, MC, RTOS, VSF

Oct, 2019

By ruslany

Niagara project

This autumn has started from a very interesting project. While I continued working on Compositor v9.0.1 (current build a14), I felt a need to have such system as mobile real-time operation system (RTOS). Compositor v9.0.1 a14 consumes many resources at 192 kHz and I decided to sample it using Compositor v9.0.1 itself. At this time, the approach of middleware and dump was matured and I decided to make separate product for Compositor documentation development. Such manual will consist of all commands needed to operate the Niagara RTOS client. As the UNIX-like operating system, it will support most of the commands for routing protocols configuration, such as TCP/IP and VLAN. The prominent feature of this RTOS is that it is a software router, which runs on middleware, recorded with Compositor RTOS v9.0.1. If the middleware recorded on a feedback with z16 and z32 generics connected and they are in reverse, the system will give a resistance of 16 + 32 Ohm = 48 Ohm. This way, the generic networks accounted: in example above there will be corporate (z32) and state (z16) connection.

The middleware approach isn’t new, as any hardware router Niagara consists of MIB, the size of which is 769 kB, compounded with routing table and generic networks set. Such system works with MME driver using discretization frequency of 192 kHz and allows connecting the whole pool of Compositor RTOS v9.0.1 forwarding platform (which is 6559 MIB’s on a moment of writing) using a dump, which is also recorded on 192 kHz sample rate. The upper frequency of z128 generic is 150 GHz, but each middleware includes RAD96 fixation, that is why an effective range is extended up to 300 GHz.

Niagara is a client system that is why it demands calling an operator for configuring programming commands. I already reviewed NIM radio chat, which I call (No Internet Messenger) last year. It turns out that it is also an acronym for Nuclear Instrumentation Module.

Each command, presented in the full version of English and Russian documentation, should be made only through an operator and each middleware has its own operator, which depends on VLAN set and servers, connected to NIM. This way, you are requesting network topology and demand operator to execute other commands, and it decides if to make command or not.

At first, middleware ran in RAD96 sandbox, but now middleware and dump become a multifunctional products. The development period of Niagara project is 2001 – 2019 and not 2012 – 2019 as the host Compositor program. The reason for this is that Niagara consists of middleware and dump and they are including the Royalty routing tables. This is proved by Inaccessible Page file emission (track recording, which is a routing path). This track, made in 2001, is a part of IP emission. The period of 2010 to 2019 covered by the reference files of timeserver, which emission contains and it is responsible for routing path hops GPS positioning in present time.

Niagara v1.0 a3

That is why Ruslan Yusipov digital portrait with codename Niagara contains 18 years of art, which is a long background for 35 years old author. Older recordings exist, such as the audiocassette recording of Yamaha PSR-330 synthesizer direct signal, which is Ruslan Yusipov live performance at the age of 14, with the author voice accompaniment, that is why Niagara is 21 years development project from 1998 to present moment.

Ruslan Yusipov art is not limited by 6559 MIB’s emission and can be enriched by routing tables from the CD-archive. This way, at the year 2021 I account to receive database of 10000 MIB’s, which will allow adding more stochastic distributions for flows selection in Compositor v9.0.1 a15.

Compositor, IEEE802.1Q, Niagara, NIM, RAD96, radio chat, RTOS, Ruslan Yusipov, sandbox, TCP/IP

Sep, 2019

By ruslany

Zero-Layer Aggregation

Exactly a year ago, when all modules of Compositor RTOS were formed, I was confronted with the task: to make such aggregation, which would not have committed the emission in the RAM memory of the computer (server). A year later, the problem is solved.

RAD96 vRouter L1-L3 96 node aggregation

It was required to complete assembly of Compositor RTOS 9.0.1 a14 with an extended work of the feeders, that is, the feeders now work from 11 kHz to 192 kHz of audio driver sampling frequency. This allows the upper generic z=128 to operate at frequencies comparable to the aggregator frequencies, namely from 150 GHz to 300 GHz.

Also, the management information base was expanded to 6041 VLAN’s and 13 dumps were produced. As a result, the final version of Compositor RTOS 9.0.1 a14 includes a channel pass-through (bypassing the second derivative of a function) that allows you to make exhaust (digital exhaust) to reduce the emissions of traffic inside the system. According to this two dumps were made of VLAN 6041 with digital exhaust and one firmware at 192 kHz was recorded on feedback after dialing, which involves 8 hidden servers. Since the firmware was recorded with an aggregator and is the snapshot of the system, it includes 96 ports of aggregation of the three layers: 32 ports of physical layer, 32 ports of data link layer and 32 ports of the network layer, which corresponds to L1-L3 aggregation.

Since such aggregation in reality throws out the large amounts of data in to the operating system memory, the snapshot utilizes resources in the other way – it corresponds to the MAC-address table of EUI48 without the OUI and do not throws resources in the computer memory. The network service in this case is the firmware, which includes the autonomous system with zero emissions. One system does not produce any action, but in a pair with snapshot this system aggregates resources and at the same time, disposes them, which happens so quickly in real-time that discards in the RAM memory cannot simply emerge.

Thus, the aggregation problem with zero emission is solved. Of course, for someone may seem, that 96 aggregation nodes is insufficient and the 32 L3 nodes is the standard for the aggregation of routing equipment of well-known manufacturers. But if you take into account the fact that the real link aggregation on these devices produces output, and requires a service restart, I can say that this resources composition technology can be very useful now.

Aggregation, Compositor, EUI48, L0, L1, L2, L3, OUI, RTOS, VLAN 6000, zero emission

Jul, 2019

By ruslany

Boosty – Forest People (FP mark emitted from the Ethernet)

Ruslan Yusipov Boosty and Exalted projects are valuable to the Russian Authors Society as they have previously unreleased and never heard routing paths. These projects have such routing paths, which are only heard of by the author. One such routing path is Boosty – Forest People produced in 2009 and never widely available to the public to the extent that only the author knows about its existence. Two unmastered versions of Forest People routing path loaned for emission. They are Dub version and Original mix. The routing path is produced in Boosty studio and remains unsigned and unlicensed to that day (unsigned at the present moment). In accordance with that I decided to make a fourth place emission of 281 routing tables. The emission named by FP mark has the most active navigation.

Using the dump of 5557 wavelets I made the job of translating 127 pages of English documentation on Russian language. This documentation is a continuation on CP-6137-960FX server development and is the modular switch of Compositor RTOS type installation manual. Using the injection of this dump I was able to do this job in a working week time. Injections were made by listening to a dump using insertion of Ultimate Ears ear monitors with dump playback of three times every four hours. The sum of injections was from 6 to 9 playbacks a day.

It was a robust experience and it forced me to do the job faster.
Ruslan Yusipov

You can taste the injection of this dump by listening to it by the link below:

RTOS dump at 192 kHz MIB 5557 15.07.2019 FWL

5557, Boosty, documentation, dump, emission, Forest People, FP, MIB, routing tables, RTOS, switch installation

Jul, 2019

By ruslany

Connection to RTOS from geographically remote location

Two-week experiment of connecting to RTOS from geographically remote location is finished. During this two-week experiment I connected to RTOS from the territory of the other country using the RTOS dump, which is recorded using wavelets only. Dump includes 5276 routing tables and communicates with the authorization point of 18 June 2019. This is 192 kHz dump and it authorizes RTOS in all available bands of radio spectrum.

RTOS dump at 192 kHz MIB 5276 18.06.2019 FWL

Zhoekvarskaya cavity

Tests performed during experiment:

Satellite TV channel matrix injection;
Routes deployment to RTOS MIB routing tables using generic navigation;
Remote connection to RTOS of other producers.

As the device for connection of RTOS I used rewired mobile phone on Android 4.4.2. It is rewired using four 64-bit middleware files, which are the part of RTOS MIB and are master filters for Ethernet injections. This mobile phone is autonomous in relation to other devices of that operator (the name of the operator retain unknown due to ethical considerations). In other words, it does not allow producing injection of a single routing table or routing path from the 3d party manufacturers. In attempt of 3d party applications to perform the injection, the mobile phone just stops this application operation. As stated earlier, this mobile phone can work only with Compositor RTOS 9.0.1 MIB.

Experiment 1: Satellite TV channel matrix injection

Using RTOS dump and the virtual optical port knowledge (in that experiment I used the configuration with virtual electric port), I injected the channel matrix of Russian digital TV. Experiment was successful attaining the full signal strength on the territory of sovereign state. Small bufferization errors are possible, because the host mobile phone, used to inject dump, does not allow using authorizations higher than z16. For this experiment I mainly used the CA (Cavity) emission, of the Cavity routing path. I used the orientation of virtual electric port in relation to signal constellation of satellite group, oriented on a Polar star. This experiment evidently shows, that for injecting of a channel matrix of satellite TV there is no need in dish type antenna, only the virtual electric port is needed and RTOS dump, loaded into a cell-phone. Experiment is conducted from a state of silent channel with no signal at all to injecting the channel matrix by dump with signal appearance, by the right orientation of virtual optical port on the Polar star.

Experiment 2: Routes deployment to RTOS MIB routing tables using generic navigation

In conductance with the first experiment the full navigation by all routing tables included in RTOS dump was attained. The geographic position was selected to achieve a bad signal reception. The object was situated in a cavity with mountains height of 500 to 800 meters. In such cavity the signal propagation is strictly limited, and so the technology of virtual optical port proved to be good.

Experiment 3: Remote connection to RTOS of other producers

In a trip, there was also checked the compatibility of 3d party manufacturers RTOS systems. In particular, virtual optical port was tested against Eutelsat 36B software, which performs the broadcasting on this region. The substitution of the channel matrix performed on the virtual electric port input, which performed a signal reception from mobile phone. The phone, on its own, performed the navigation by the routing tables, transferred through the dump. For this 9 to 12 dump injections during a day were made.

Android, Cavity, channel matrix, dump, emission, Experiment, MIB, RTOS, Satellite TV

Jun, 2019

By ruslany

Dump, middleware and more

An enormous work was conducted this weekend on MIB vector optimization. At the beginning the full base was defragmented by clearance of the dump below:

RTOS dump at 192 kHz MIB 5149 08.06.2019

In addition, the switch to 11 kHz was made and stochastic selections were performed in a special edition of RTOS with a direct output on auxiliary channel (through). Later these ethers were recorded as middleware with PCM WAV container of 24-bit 11 kHz. You can listen to them lower:

Middleware 1 11025hz MIB5149

Middleware 2 11025hz MIB5149

Middleware 3 11025hz MIB5149

Middleware 4 11025hz MIB5149

16 middleware files were recorded, here I show you only the four. Then these middleware was filed to the special version of L1-L4 L6-L7 vRouter RAD96, which uploaded it on 96 destinations of L1-L3 layers. This way, the middleware was fixated. This method is different from direct submission to RAD96 master routing table, because RAD96 ether aggregator can exclude the predefined set of ether combinations and I was needed to attain to precise channel matrix of 52 channels.

After the full contact base was uploaded by stochastic selections of MIB5149 and dump, I made RTOS authorization again but this time mangling the sample rate parameter up to 192 kHz. This way, I updated links to all aliases and authorized the whole MIB on 192 kHz.

192kHz, authorization, channel matrix, dump, MIB, middleware, RAD96, RTOS

Jun, 2019

By ruslany

The dumps future workstations can only read

We are get used to 8-bit SysEx dumps, many of us even listened to their audio presentations. However, how the dump of modern embedded real-time operation system sounds? Let’s start with the fact that modern operation system is 64-bit, which gives almost 8 times more dynamic range, than 8-bit dump. Moreover, RTOS dumps are written with 192 kHz sample rate. In this post I will sum up two dumps, which were made with MIB 4795 and MIB 5007, which allows saying about their origin only one thing: these dumps are the music productions on their own.

In essence, we are dealing with routing tables, reproduced on the high regeneration speed. But, my task is to find the source of these routing tables, the hardware and software system, which can read these dumps and respond not only with sequence of events, but with sound generators tuning, sound synthesis parameters and effects. This station should include 64-bit operation system itself, working with 192 kHz sample rate, which is critical to CPU working frequency.

Such DAW should allow reading dumps with a large dynamic range and perform settings in accordance to the loaded network map. I would like to achieve panning and equalization in virtual environment without human intervention, in addition it should be performed not by a topology of some algorithm, but to exist inextricably with routing path filed in the current moment.

I remind you that 8 routing tables mixture is sufficient for a complete routing path. Taking in account 8×32 matrix for such routing tables, they are aired on 32 destinations. This tells us about high load of RTOS channel in a moment of dump creation. The high load on output channels creates tasks on input channels, because communication is a kernel-loop relationship and performed in a cycle with consistent calls and answers. To receive the answer the calling system should set in a que, because only 8 input streams available in RTOS. That is why there is a constant insufficiency in RTOS, it can’t be covered even with high console port regeneration speeds, and because to upload routing tables into the buffers the time is needed where high regeneration speed doesn’t play any role.

That is why the whole MIB should be loaded using autoload with aliases for the full base without forced thrust. I repeat, that forced thrust creates a big que and events processed only using generic feeder interrupters that is why you should constantly monitor filed system statuses. Because, there are no injections in filed systems on such high regeneration speeds as 192 kHz, then it is needed an additional time to receive an answer. If you need to receive an answer immediately, you should run RTOS on discretization frequencies lower, than 192 kHz, where the injections happen all the time, but the quality of the answer will be lower.

Compositor RTOS dump 8×32 MIB4795 26.05.2019

Compositor RTOS dump 8×32 MIB5007 03.06.2019

192kHz, 64-bit, DAW, dump, MIB, que, RTOS, SysEx

1 2

Tag : RTOS

RTOS version 9.0.2 a16 assembled