Disclosed is an approach for implementing a flexible parser for a networking system. A micro-core parser is implemented to process packets in a networking system. The micro-cores of the parser read the packet headers, and perform any suitably programmed tasks upon those packets and packet headers. One or more caches may be associated with the micro-cores to hold the packet headers. A dependency list is used to maintain proper ordering of packets being processed by the micro-cores.
The present disclosure is directed towards circuits for network traffic processing.
To support high performance networking, networking components within computing and telecommunications systems must be able to effectively process numerous different flows (e.g. groups of packets originating from a common source). As performance expectations for such systems increase over time, these systems are challenged to implement more and more complex packet-handling tasks at ever greater speeds.
One common task to be handled in order to implement a networking system is to process and analyze the packets in a communications flow. A parser is used to review the header of the packet, which allows the communications system to understand how that packet should be directed and handled. Accordingly, there is a need for an improved approach to implement a parser for networking systems.
An approach is described for implementing a flexible parser for a networking system. According to some embodiments, a micro-core parser is implemented to process packets in a networking system where a dependency list is used to maintain proper ordering of the packets being processed by the micro-cores. The micro-cores of the parser read the packet headers, and perform any suitably programmed tasks upon those packets and packet headers. One or more caches may be associated with the micro-cores to hold the packet headers.
Other and additional objects, features, and advantages are described in the detailed description, figures, and claims.
FIG. 1 shows a system for processing packets using a parser that is implemented with one or more micro-cores in accordance with some embodiments.
FIG. 2 illustrates a more detailed architectural diagram of a parser that utilizes micro-cores in accordance with some embodiments.
FIG. 3 shows a flowchart of an approach for utilizing one or more micro-cores in a parser in accordance with some embodiments.
FIG. 4A illustrates an example dependency list structure.
FIG. 4B shows a flowchart of an approach for adding information to a dependency list structure in accordance with some embodiments.
FIGS. 5A-D provide an illustrative example for adding information to a dependency list structure.
FIG. 6 shows a flowchart of an approach for using a dependency list structure in accordance with some embodiments.
FIGS. 7A-G provide an illustrative example for using a dependency list structure.
FIG. 8 shows a flowchart of an approach for allocating packets to a specific micro-core in accordance with some embodiments.
FIGS. 9A and 9B illustrate example systems in which a micro-core based parser may be employed.
FIG. 10 illustrates an example ingress path subsystem in which a micro-core based parser may be employed.
FIG. 11 illustrates the architecture of an example micro-core.
FIG. 12 illustrates functional components of an example micro-core.
Embodiments of the present invention will now be described in detail with respect to the drawings, which are provided as illustrative examples. Notably, the figures and examples below are not meant to limit the scope of the embodiments to a single embodiment, but other embodiments are possible by way of interchange of some or all of the described or illustrated embodiments. Whenever convenient, the same reference numbers will be used throughout the drawings to refer to the same or like parts. Where certain elements of these embodiments can be partially or fully implemented using known components, only those portions of known components that are necessary for understanding of the embodiment will be described, and details descriptions of other portions of such known components will be omitted so as to not obscure the description. In the present specification, an embodiment showing a singular component should not be considered to be limiting; rather, other embodiments may include a plurality of the same components, and vice versa, unless explicitly stated otherwise. Moreover, applicants do not intend to for any term in the specification or claims to be ascribed an uncommon or special meaning unless explicitly set forth as such. Further, embodiments may encompass present and future known equivalents to the components referred to by way of illustration.
An approach is described for implementing a flexible parser for a networking system. According to some embodiments, a micro-core parser is implemented to process packets in a networking system. The micro-cores of the parser read the packet headers, and perform any suitably programmed tasks upon those packets and packet headers. One or more caches may be associated with the micro-cores to hold the packet headers.
FIG. 1 shows a system 20 for processing packets 12 using a parser 2 that is implemented with one or more micro-cores 4 a-n (also referred to herein as "μcores") in accordance with one embodiment. The parser may be used in conjunction with any processing system, such as a multi-core host processor 6. A multi-core processor is an integrated circuit that contains multiple microprocessor cores, which effectively multiplies the performance of the circuit in correspondence to the number of cores 8 a-j. Therefore, the cores 8 a-j shown in FIG. 1 correspond to conventionally understood microprocessor cores that are used to implement a multi-core processor. These cores 8 a-j are distinguishable from the micro-cores 4 a-n in the parser 2, which have a smaller layout footprint as compared to conventional processor cores that are included as processing blocks within a larger integrated circuit. The micro-cores may include elements similar to standard processors cores (such as an instruction RAM and data RAM), but are small enough to allow placement as needed within specialized processing engines/accelerators on a processing system, and which can work in conjunction with the main host processors and processor cores. A micro-core is a small microprocessor, with, for example, a standard single issue pipe-line (e.g., a single issue, 5-stage pipe-line). In some embodiments, a micro-core only has access to local resources, so that the execution latency is deterministic. In some embodiments, the instruction RAM, data/stack RAM, and packet RAM are all local to a micro-core, and there is no access to off-chip resources or other accelerators that can make per-packet execution latency unpredictable.
The parser 2 is operable to parse the plurality of packets 12 to gather packet information. Each of the micro-cores 4 a-n within parser 2 may be implemented as a programmable state machine capable of parsing packets from one or more networks and of one or more protocol types. One or more instruction caches are used to hold programming logic for the microcores 4 a-n, to provide the parsing functionality of the micro-cores 4 a-n.
The parser 2 may be instructed to perform any suitable processing function upon the packets 12. For example, the micro-cores 4 a-n in the parser 2 may parse packet header information for the packet 12 to provide inputs for hash logic 16. Hash logic 16 is operable to perform a hash algorithm utilizing a key to generate a hash. The packets 12 are allocated for subsequent processing based at least in part on the key/hash generated by the parser 2 and hash logic 16. For example, the packets 12 may be allocated for processing to a specific core 8 a-j within a multi-core processing system 6, and/or to a specific thread within one of the cores 8 a-j. Some reasons for allocating the packets 12 to different cores 8 a-j or to different threads within the cores 8 a-j include, for example, to implement load-balancing and/or flow-binding. Load balancing refers to balancing a processing load equally or nearly equally among a group of cores/threads. Flow-binding refers to directing a flow of processing to specific threads or processor cores.
The allocation of the packets to the different cores 8 a-j is performed by utilizing the key generated by the hash logic 16, where the key refers to any suitably unique identifier. In one embodiment, the key may be formed by performing multiple field extractions from at least one of the packets. In another embodiment, the key may be formed using the packet information. Any suitable hash algorithm may be utilized to generate the hash. For example, in one embodiment, the hash logic 16 may include a cyclic redundancy check (CRC) algorithm. As an option, the hashing logic 16 may include a CRC algorithm with a programmable polynomial.
The system 20 may further include memory 10 to which the packets 12 are written. In some embodiments, the packets 12 are parsed before the packets 12 are written to the memory 10. In addition, the hash logic 16 may also be performed before the packets 12 are written to the memory 10. Additionally, the packets 12 may be allocated to the cores 8 a-j before the packets 12 are written to the memory 10. In another embodiment, the packets 12 may be written to the memory 10 simultaneously or nearly simultaneously with the parsing, hashing, and/or allocation.
In operation, the packets 12 may be transferred to the parser 2 and written to the memory 10. While packets are being received and transferred to the memory 10, the parser 2 may examine the arriving packet data and extract certain data (e.g. user-definable fields, keys, and/or identifiers) from the packet header. The parser 2 may then concatenate these fields together to form a key (e.g. a 128-bit key, etc.) used by a packet director to classify and dispatch the packet. The key may be dispatched to a messaging network (e.g., messaging network 1E02, FIG. 9B) for use in allocating the packets. In addition, the key may be padded in front of the packet, and a descriptor (containing the start address) of the packet may be dispatched to a thread using the messaging network. In this case, the descriptor may be allocated to processor threads or a plurality of processing cores for executing the threads. Using the descriptor, the packet data may be retrieved from the memory 10, where the packet may be stored in the memory 10 (e.g. a cache) and a location of the packet is passed through the messaging network in the key, as opposed to passing all of the packet data through the messaging network. The key may be provided to one or more threads or processing cores utilizing a work queue, e.g. a first in, first out (FIFO) queue.
Each of the micro-cores 4 a-n can be instructed to perform one or more packet processing tasks, e.g., by reading in instructions from an instruction cache that is associated with the micro-cores 4 a-n. This permits the parser 2 to be flexible enough to operate upon any packet format or to perform any instructable task, simply by changing or updating the instructions that are sent to the parser 2. For example, the packets may include packets of different and multiple protocol types. The parser 2 may extract multiple fields (e.g., for multiple protocols) and identify multiple layer headers (e.g. layer headers in a multi-layer network protocol design). Furthermore, the parser 2 may support TCP/UDP and IP checksum verification.
FIG. 2 illustrates a more detailed architectural diagram of a parser 201 that utilizes micro-cores. There may be any number of micro-cores 204 a-n in the parser 201. For example, a parser in some embodiments may implement sixteen separate micro-cores 204 a-n. Packets 212 are received into a buffer 252, where the buffer 252 includes a bank of FIFOs that forms an input queue of packets waiting to be processed by the parser 201.
The incoming packets 212 that have been received within the buffer 252 are scheduled/assigned to respective micro-cores 204 a-n. Any suitable scheduling algorithm may be employed to assign packets in the queue to the micro-cores 204 a-n. For example, a round-robin scheduling algorithm may be employed to assign packets 212 to micro-cores 204 a-n as they become available. In addition, as described in more detail below, it is possible to schedule packets to specific ones of the micro-cores, e.g., because certain micro-cores are specifically programmed to handle certain tasks, protocols, or packet types differently from the other micro-cores.
Each micro-core 204 a is associated with one or more caches 214 a and 214 b. In some embodiments, the cache 214 a/b is limited to a sufficient size to store the header of an incoming packet 212. As such, the entirety of a packet 212 is not sent to the micro-core 204 a. Instead, only the first n bytes of the packet 212 (e.g., the bytes forming the header) are directed to the micro-core 204 a. In some embodiments, the cache 214 a/b is sized at 512 bytes, so that the first 512 bytes of a packet 212 would be loaded into the cache 214 a/b.
Multiple caches 214 a and 214 b may be associated with a single micro-core 204 a, to allow that micro-core 204 a to operate at or near its full capacity with minimal downtime. During the time that the micro-core 204 a is operating upon a packet in a first cache 214 a, the second cache 214 b can be filled in with a new packet or emptied of a completed packet. As soon as the micro-core 204 a has finished processing the packet in the first cache 214 a, that micro-core 204 a can immediately begin processing the packet that had been concurrently loaded into the second cache 214 b. The first cache 214 a can then repeat the cycle of emptying the completed packet and loading a new packet. Each of the caches 214 a and 214 b can be sized to the maximum threshold memory size to store the packet header.
In some embodiments, each micro-core 204 a is associated with a instruction cache/memory 254. The instruction cache/memory 254 stores the operational programming that the micro-core 204 a performs to process the packet headers. The programming in the instruction cache/memory 254 may be used to perform any suitable task by the micro-core 204 a upon a packet. For example, the micro-core 204 a can operate to perform classification operations on the packets. In addition, the micro-core 204 a can operate to drop packets and ensure that the packets are not forwarded to subsequent engines or processing cores.
The output from the micro-core 204 a is sent to any downstream component 260 that consumes the output from the parser 201. For example, the packet header (when suitably combined with the packet data) can be sent to a DMA 230 for storage and later access. The micro-core 204 a can also output information to assist a descriptor generator 232 in generating a descriptor for the packet. For example, the micro-core 204 a can be used to forward identification of free FIFOs to the descriptor generator 232. The micro-core 204 a may be used to generate a key that is used by hash logic 234 to generate a hash value. The information generated by the micro-core 204 a may also be directed to a packet ordering engine 236 to assist in ordering the packets to be processed by the networking system. Generally, the micro-core 204 a may provide data used by other packet processing engines and mechanisms 238 within the networking system.
A dependency list 220 is employed to make sure packets 212 are processed and released by the micro-cores 204 a-n in their proper order. This dependency list is used to make sure that a later packet within a given flow is not released unless an earlier packet has already been processed and released.
FIG. 3 shows a flowchart of an approach for utilizing a micro-core based parser (e.g., parser 201, FIG. 2) to process packets in a networking system. At 302, a packet is received in the networking system for processing. The packet may be received over one or more physical interface connections and/or data channels. The packet may also be stored and/or queued in various interface and receiving buffers (e.g., buffer 252) when it has been received for processing.
At 304, the packet is scheduled to a selected micro-core for processing. Any suitable scheduling algorithm may be employed to schedule the packets. For example, a simple round robin scheduling algorithm may be employed to assign packets to micro-cores. In addition, more complicated queuing and scheduling algorithms may be employed to ensure fair scheduling of the packets. The scheduling activity may also be performed in reliance upon available hardware resources, where scheduling is delayed until sufficient resources are available to handle the processing results from the micro-cores. Packets can also be assigned to individual micro-cores that have been programmed to perform specific tasks. For example, one of the micro-cores may be specially programmed to handle a unique protocol, and every packet compliant with that unique protocol would be assigned to that micro-core.
At 306, the packet header is loaded into the cache (e.g., cache 214 a or 214 b) for its assigned micro-core. The cache can be automatically populated with new packet headers as it becomes available. One example criteria that may be used to automatically populate the cache is a determination of the number of bytes received, e.g., a number greater than a programmed threshold could be used to control whether the cache is loaded with the packet header. In some embodiments, the maximum value of this threshold is 512 bytes. Another example criteria that can be considered is whether there are sufficient hardware resources to process the packet. For example, a determination can be made whether there are sufficient free descriptors that are available for that packet to be able to exit the microcode once the processing is completed.
At 308, the micro-core processes the packet header, e.g., where the micro-core performs one or more ingress functions to process the packet in a networking engine. For example, the micro-core may operate to parse the first n bytes of the packet (e.g., up to the first 512 bytes) to determine the destination of the packet within a host processor or host processor core. If appropriate, the micro-core may also operate to drop the packet, e.g., if the micro-core performances analysis that determines that it is appropriate to drop the packet for lack of a suitable destination. The micro-core may also be operated to modify one or more bits in an ingress descriptor to communicate information derived from the ingress (e.g., an ingress MAC or parsed header) to a downstream component, such as downstream host processor/core.
In addition, the micro-core may add a pre-pad to the packet. For example, consider an example packet format in which a certain portion of the packet is left open, e.g., such that the first 64 bytes of the packet are left open. This open portion of the packet can be occupied by data inserted by the micro-core to communicate parsed information to a downstream component, such as a host processor/core. For example, the 64 bytes pre-pad can be filled in 16, 32, 48 or 64 byte portions before the packet data.
At 310, after processing by the micro-cores, the packets may be released to downstream components (e.g., components 260). A dependency list (e.g., list 220) is used to ensure that the packets are released in an appropriate order.
FIG. 4A illustrates an example structure 400 that can be used to implement a dependency list in some embodiments. Structure 400 is implemented as a set of rows and columns, where each row of the structure 400 corresponds to a bit vector that identifies the dependencies of a specific packet in a micro-core. Each bit in a row can be used to identify whether the packet corresponding to that row has a dependency to another packet, e.g., by setting a "1" value in a bit position to indicate a dependency and a "0" value to indicate no dependency. Therefore, a row having all "0" values means that the corresponding packet does not have any dependencies, and can be released upon completion of processing by the micro-core. However, the presence of one or more "1" values for the bit vector in a row means that the corresponding packet has a dependency to at least one other packet, and hence cannot be released until the other packet(s) have been released.
Each column corresponds to the dependencies that other packets have to a given packet. As a packet is added to a row in the structure 400, it will include "1" values in the columns for the earlier packets in the same flow. Subsequent packets in the same flow will have rows that are modified to include a "1" value in the column that corresponds to that earlier packet.
The example structure 400 shown in FIG. 4 is organized for a parser that utilizes sixteen micro-cores (micro-cores 0-15). Therefore, there are sixteen separate rows that correspond to packets which are received for each of the sixteen micro-cores, where each row identifies the dependencies for its associated packet. Similarly, there are sixteen columns that correspond to each of the sixteen micro-cores, where each column identifies any other packets that have a dependency on the packet associated with that column.
Each packet may be associated with queue identifiers 401 a-n that identify the packet's positioning in a scheduling queue. When that packet is received/scheduled for processing by a micro-core, the specific queue identifier for that packet is associated with the row in the structure 400.
Any hardware, software, or combination of hardware and software may be employed to implement dependency list structure 400. For example, the dependency list structure 400 may be implemented using a content addressable memory (CAM).
FIG. 4B shows a flowchart of an approach for populating a dependency list structure 400 according to some embodiments. At 402, a packet is received for processing. This action is taken, for example, when the cache associated with a micro-core has been populated with the packet header, and is ready to be parsed by the micro-core for processing.
At 404, the row in the dependency list structure that corresponds to the micro-core is associated with the packet. This occurs, for example, by associating the queue identifier for the packet to the specific bit vector for that micro-core's row in the dependency list structure.
The bit vector in the row is then populated at 406 with bit values that appropriately identify the dependencies for the packet associated with the bit vector. For example, the column position for each earlier packet in the same flow is marked with a "1" value to indicate the dependency and the column position for a packet for which there is no dependency is marked with a "0" value.
FIGS. 5A-D provide an illustration of this process. FIG. 5A shows a dependency list structure 500 that has not yet been populated with bit vectors associated with any packets. In other words, there are currently no packets being processed by any micro-cores represented by the dependency list structure 500.
Assume that a packet has been received for processing by a given micro-core (e.g., micro-core 0). As shown in FIG. 5B, the row 504 in the dependency list structure 500 associated with micro-core 0 is populated with a bit vector for that packet. In the current situation, each bit position in the bit vector is marked with a "0" value to indicate that there are no current dependencies for this packet, which makes sense since there are no earlier packets in this flow which are currently being processed by another micro-core.
Next, assume that another packet is received in the same flow for processing, but this time by micro-core 7. As shown in FIG. 5C, the row 506 in the dependency list structure 500 associated with micro-core 7 is populated with a bit vector for that packet. Since the packet associated with row 506 is within the same flow as the packet associated with row 504 but is later in time, a dependency is indicated in the bit vector associated with row 506. Column 507 is associated with the micro-core 0 that is handling the earlier packet (i.e., the micro-core 0 handling the earlier packet represented in row 504). Therefore, the bit value in column 507 for row 506 is marked with a "1" value to indicate the dependency. Each other bit position in the bit vector for row 506 is marked with a "0" value to indicate that there are no other current dependencies for this packet.
Assume that yet another packet is received in the same flow for processing, this time by micro-core 12. As shown in FIG. 5D, the row 508 in the dependency list structure 500 associated with micro-core 12 is populated with a bit vector for that new packet. Since the packet associated with row 508 is later in the same flow as compared to the packets associated with rows 504 and 506, multiple dependencies need to be indicated in the bit vector associated with row 508. Like the bit vector for the packet associated with row 506, the column 507 associated with the micro-core 0 is modified to include a bit value in this column for row 508 (e.g., a "1" value) to indicate the dependency. Column 509 is associated with the micro-core 7 that is handling the earlier packet (i.e., the micro-core 7 handling the earlier packet represented in row 506). Therefore, the bit value in column 509 for row 508 is marked with a "1" value to indicate the dependency. Each other bit position in the bit vector for row 508 is marked with a "0" value to indicate that there are no other current dependencies for this packet.
When a packet is to be released, the dependency list structure is checked to determine whether that packet is associated with any dependencies that should prevent release of that packet. This is to make sure that a packet later in a flow is not released until any earlier packets in that same flow have already been released.
FIG. 6 shows a flowchart of an approach for using a dependency list structure to manage release of packets according to some embodiments. Release of a packet includes release of the portion of packet data provided to the parser. For example, in some embodiments only the packet header is provided to the parser; release of the packet thus includes release of the header from the parser. At 602, a packet is identified for which packet parsing has been completed. This action may be taken, for example, when the micro-core associated with a packet has completed its processing, and provides a signal indicating that it is ready to release the packet to one or more downstream components.
At 604, the bit vector associated with the packet is checked to determine whether there are any dependencies for that packet. This action is taken by reviewing the bit values in the bit vector associated with the packet, and checking whether there are any bit values indicative of a dependency, e.g., by checking whether there are any "1" values for any bits in the bit vector.
The action to be taken at this point depends on whether any dependencies have been identified. From decision box 606, if there are no identified dependencies, then the packet can be immediately released at 608. However, if there are any identified dependencies, then the packet cannot be immediately released. Instead, a wait state 610 occurs to wait for the release of the earlier packet(s). After waiting, the procedure loops back to 604 to re-check the status of any dependencies. If all dependencies have been cleared, then the packet can be released at 608. The loop is repeated if there are still any remaining dependencies.
FIGS. 7A-F provide an illustration of this process. FIG. 7A reproduces the dependency list structure 500 from FIG. 5D, which has already been populated with bit vectors associated with packets. Recall from the earlier discussion that the first packet in the flow is being handled by micro-core 0, and hence is represented by the bit vector associated with row 504. The second packet in the same flow is being handled by micro-core 7, and hence is represented by the bit vector associated with row 506. The bit vector associated with row 506 includes a bit value in column 507 indicative of a dependency on the packet being handled by micro-core 0. The third packet in the same flow is being handled by micro-core 12, and hence is represented by the bit vector associated with row 508. The bit vector associated with row 508 includes a bit value in column 507 indicative of a dependency on the packet being handled by micro-core 0, and also includes a bit value in column 509 indicative of a dependency on the packet being handled by micro-core 7.
At the current moment in time, the packets associated with micro-cores 7 and 12, represented by rows 506 and 508, respectively, cannot be released since the bit vectors for each of these packets indicates at least one dependency, e.g., because there is at least one "1" values for a bit in each of these bit vectors. However, the bit vector represented in row 504 for the packet being handled by micro-core 0 does not show any dependencies, e.g., because every bit position shows a value of "0" in the bit vector.
Assume that micro-core 0 has completed the required processing for its packet represented by row 504, and therefore is to release this packet. The bit vector in row 504 for this micro-core 0 is checked to see if there are any dependencies. Since there are no dependencies indicated by the bit vector (e.g., because all bit values are "0"), the packet can be immediately released. As shown in FIG. 7B, the bit vector in row 504 associated with this packet/micro-core is cleared, and the micro-core 0 can now be assigned to process another packet. In addition, any dependencies by other packets upon this packet can also be cleared. This is accomplished by setting the bit values in the column associated with the micro-core to indicate release of the packet. Here, column 507 is associated with micro-core 0. Therefore, the values that had previously been set in this column to indicate dependencies can now be changed to indicate release of the dependency, e.g., by changing bit value "1" in column 507 for rows 506 and 508 to a bit value of "0".
FIG. 7C shows the current state of the dependency list structure 500 after these changes to the bit vectors. At the current moment in time, the packet associated with micro-core 12 represented by row 508 cannot be released since the bit vectors for this packet indicates at least one dependency, e.g., because there is at least one "1" values for a bit in this bit vectors. However, the bit vector represented in row 506 for the packet being handled by micro-core 7 does not show any dependencies, e.g., because every bit position shows a value of "0" in the bit vector.
Assume that an instruction is received to release the packet being handled by micro-core 7. The bit vector in row 506 for micro-core 7 is checked to see if there are any dependencies. Since there are no dependencies indicated by the bit vector (e.g., because all bit values are "0"), the packet can be immediately released. As shown in FIG. 7D, the bit vector in row 506 associated with this packet is cleared, and the micro-core 7 can now be assigned to process another packet. In addition, any dependencies by other packets upon this packet can also be cleared. This is accomplished by setting the bit values in the column associated with the micro-core to indicate release of the packet. Here, column 509 is associated with micro-core 7. Therefore, the values that had previously been set in this column to indicate dependencies can now be changed to indicate release of the dependency, e.g., by changing bit value "1" in column 509 for row 508 to a bit value of "0".
FIG. 7E shows the current state of the dependency list structure 500 after these changes to the bit vectors. At the current moment in time, the packet associated with micro-core 12 represented by row 508 can be released since the bit vectors for this packet indicates that there are no dependencies for this packet, e.g., because every bit position shows a value of "0" in the bit vector.
Assume that an instruction is received to release the packet being handled by micro-core 12. The bit vector in row 508 for micro-core 12 is checked to see if there are any dependencies. Since there are no dependencies indicated by the bit vector (e.g., because all bit values are "0"), the packet can be immediately released. As shown in FIG. 7F, the bit vector in row 508 associated with this packet is cleared, and the micro-core 12 can now be assigned to process another packet. In addition, any dependencies by other packets upon this packet can also be cleared. Here, there are no dependencies by other packets upon this packet, therefore, no bits are reset at this time. FIG. 7G now shows the current state of the dependency list structure 500 after this change to the bit vectors.
When assigning packets to micro-cores, packets can be scheduled to specific ones of the micro-cores. FIG. 8 shows a flowchart of an approach for directing packets to specific micro-cores according to some embodiments. At 802, a packet is received for scheduling. For example, the packet may have been received into a receive buffer 252 (FIG. 2) having a set of FIFOs, where the packet is placed into one or more of the FIFOs.
When the packet is received for scheduling, then at 804 that packet can be checked to see if it should be assigned to a specific micro-core (e.g., a specific one of micro-cores 204 a-204 n). For example, certain micro-cores may be specifically programmed to handle certain tasks, protocols, or packet types differently from the other micro-cores. The packet can be analyzed to determine whether it pertains to one of the specially programmed micro-cores.
One approach that can be taken to implement this action is to use an interface mask to spray the incoming packets to different ones/sets of micro-cores based on the specific interface through which the incoming packet was received. The mask bits differentiate the packets between the different interfaces, so that certain packets from certain interfaces are directed to corresponding micro-cores. The parsing function can be different for the different micro-cores, e.g., because of different contents of the instruction RAMs for different interfaces for the different micro-cores.
At 806, the packet is thereafter scheduled for the identified micro-core. When the cache for the micro-core is available, the packet header for the packet is loaded into that cache for parsing/processing by the micro-core.
Embodiments may be utilized in any suitable network processing system or subsystem. For example, the micro-core-based parser can be used in a network acceleration engine (NAE) of a network processor.
FIG. 9A is a diagram illustrating an exemplary system 900 that employs a micro-core-based parser, in accordance with at least one embodiment of the present disclosure. In particular, this figure shows a network acceleration engine (NAE) 910, which includes a packet ingress subsystem 930 that performs parsing and classification of incoming packets that are received from the ingress ports 946 of the network interface 904. In some embodiments, the packet ingress subsystem 930 performs its parsing and classification functions using a dedicated hardware parser and a number of programmable micro-core processors, e.g., sixteen micro-core processors.
The NAE 910 provides packets to a packet ordering engine (POE) 920 that is responsible for ensuring that data packet fragments belonging to a specific flow are transmitted by the packet egress subsystem 940 in the same order in which they were received by the packet ingress subsystem 930. The packet egress subsystem 940 transmits packets outward through the egress ports 948 in the network interface 904. The packet data path to communicate packets in system 900 includes an I/O distributed interconnect 942. The message data path to communicate messages in system 900 includes a messaging network 933.
System 900 employs free descriptor queues that are divided into any number (e.g., twenty) descriptor pools. Descriptors are message units of specially formatted words (e.g., 64-bit formatted words). For the NAE 910, each descriptor points to a pre-allocated data buffer in memory where packet data will be stored. Free-in messages are used to initialize the descriptors in the pools. The micro-core processors in the NAE Packet Ingress Subsystem 930 are used to determine which descriptor pool to draw descriptors from for each data packet, which thereby determines where each data packet will be written in memory.
FIG. 9B depicts an example processing system 100E that may utilize the network acceleration engine 900 of FIG. 9A. The processing system 100E has three bidirectional communication rings (each depicted as a bold-line oval), a plurality of CPUs (e.g. Core-0, Core-1, etc), a plurality of accelerators (e.g. Network Acceleration Engine, POE, Interlaken-LAI) to perform a set of operations, and a plurality of IO blocks (e.g. ICI, general purpose I/O 1E06, etc). The three rings can be used for referring to and/or moving packets within the context of an on-chip network.
As shown, each instance of the plurality of CPUs (e.g. Core-0, Core-1, etc) comprises its respective level two cache (e.g. the respective L2 cache, as shown), and comprises its respective level one cache for instructions (e.g. the respective L1-I cache) and its respective level one cache for data (e.g. the respective L1-D cache). Each of the CPUs has a virtual CPU (e.g. 1E040, . . . 1E043) depicted as an oval within a core. These CPUs are separate from the micro-cores in the parser in the Network Acceleration Engine.
In some embodiments, the Memory Distributed Interconnect 1E32 (MDI) comprises a memory interconnect ring, the messaging network 1E02 comprises a messaging ring, and the I/O distributed interconnect 1E42 (IODI) comprises an IO interconnect ring. Also shown is a packet ordering engine (POE) to distribute packets in a particular order to a networking output. In this embodiment, the POE connects to the network acceleration engine (shown as, Network Accel Engine).
In the embodiment shown, the processing system 100E includes an L3 cache to connect to the MDI ring 1E32. The interconnect serves to connect memory elements to other memory elements, possibly using a message station or direct memory access logic. For example, in some embodiments, an instance of a CPU (e.g. Core-0) includes one or more cache memories local to the CPU, and the local cache can be connected to the Memory Distributed Interconnect 1E32 ring. A memory interconnect ring 1E32 can be configured to any width, including any width of any interconnected memory, or even multiples of widths of any interconnected memory, or even fractions of the width of any interconnected memory.
The processing system 100E depicts an I/O distributed interconnect 1E42, which I/O distributed interconnect 1E42 serves to connect IO blocks (e.g. PCI-E, POE, etc) and accelerators (e.g. network acceleration engine, security engines) to each other, and to the messaging network 1E02 (as shown).
The accelerators can be located and configured to perform any specific operation. In some cases, one or more accelerators can be configured to perform such a specific operation autonomously (e.g. without intra-operation intervention by a CPU) and, in some cases, one or more accelerators can be configured to perform operations under programmatic control, which programmatic control can be implemented in any combination of configuration registers and sequencing units (e.g. a finite state machine, a micro-sequencer, etc). The Interlaken LA/PCI-E (104) may be a single module or two separate modules. The Interlaken LA of 104 may be individually enabled or disabled while the PCI-E is always enabled in some embodiments. The Interlaken LA/PCI-E (104) interacts with a number of devices that are outside the boundary of the processing system 100E, and the number of devices may include, for example, a knowledge-based processor or any look-aside devices 102 (identified as a content-addressable memory or CAM), a host, and peripherals and I/O.
Further details regarding an exemplary processing system that may be used to implement the system of FIG. 9B is described in U.S. patent application Ser. No. 13/107,809 filed May 13, 2011, entitled "IMPLEMENTING INTEGRATED NETWORKING FUNCTIONS AT WIRE SPEED", which is hereby expressly incorporated by reference in its entirety.
FIG. 10 depicts a block diagram of an ingress path subsystem for a NAE according to some embodiments. The main function of the ingress path subsystem in this example is to receive packets from the network interface and store those packets, via the DMA 1036, into pre-allocated buffers in a memory subsystem.
The packet data is received through one or more interfaces 1008 (e.g., through the four Quads 1002). Quads 1002 may be implemented as Serdes lines, where the Quads 1002 take care of the networking interface protocols for receiving the incoming packets over the network interface 1008. The incoming packets are placed into interface FIFOs 1010, e.g., twenty interface FIFOs having a total of 16 KBytes. The slot generator 1006 generates slots based on interface bandwidth requirements. The slot generator 1006 can be programmed to divide up the bandwidth usage as appropriate. A credit mechanism can be utilized to prevent overflows at the interface FIFOs 1010. The SGMII interface 1004 is provided to receive control/management input to the system.
The packet data is read from the interface FIFOs 1010 into a receive buffer (RX buffer 1020). In the current example, the Rx Buffer is carved into 524 "contexts", where a context refers to a separation of the incoming packet streams, e.g., based at least in part on physical input ports and/or stateless packet parsing, such as VLAN-priority for Ethernet interface or the channel number for an Interlaken interface. The packets from the interface FIFOs 1010 can be mapped into the different FIFOs within the RX buffer 1020. For example, a given packet in an interface FIFO may be mapped to a base 0/1 set of RX FIFOs 1011 in the RX buffer 1020.
An arbiter 1022 acts as a scheduler to read packet data from the RX buffer 1020 and to feed the packet data for parsing to parser 1028. Any suitable scheduling algorithm may be employed at the arbiter 1022. For example, a round-robin approach can be taken to read out of the Rx Buffer 1020. Interface masking may also be applied to direct packets from specific interfaces to specific micro-cores in the parser 1028. In addition, scheduling by the arbiter 1022 may also be dependent upon available of hardware resources and free descriptors. Before being considered eligible for scheduling, the total Rx bytes in a context should be greater than a programmable threshold or an end-of-packet (EOP) indication for that section should be present in the Rx buffer.
The parser sequencer 1016 receives control information for the packets. For example, the parser sequencer may receive information about the packets such as the length or start address of the packets. This information is used by the arbiter 1022 to schedule reads of packet data from the RX buffer 1020 into the parsers.
A hardware parser 1024 may be employed to perform parsing on the packet data, in conjunction with the activities of the micro-core parser 1028. For example, the hardware parser 1024 may be used to generate a classification key for each incoming packet. The classification key for the incoming packet is sent to one of the programmable micro-cores in the micro-core parser 1028 for any extra classification processing that may be needed.
In some embodiments, the micro-cores within the micro-core parser 1028 are fully programmable processors, as described in more detail below. The programmability of these micro-core processors allows for great flexibility and expansion of the capabilities of the system to perform packet parsing.
As data moves from the RxBuffer 1020 to the parser 1028 and DMA 1036, the Rx descriptor generator 1032 detects when a packet crosses a page boundary. When a start of packet (SOP) indication is received, or when a packet crosses a page boundary, the Rx descriptor generator 1032 generates a new free descriptor from the free descriptor queue 1014 and sends the pointer to DMA 1036. Packet descriptors for the same packet can be from the same Free Descriptor Queue 1014. The DMA block 1036 will pre-pad information to the packet buffer and store the packet data via an I/O distributed Interconnect. The Rx descriptor generator 1032 also adds the new descriptor to a descriptor list. The RX descriptor generator 1032 may also create a descriptor that points to the list of descriptors where the packet was stored and sends this descriptor along with the Flow ID, Class ID, and other control information 1038 to the Packet Ordering Engine (POE) 1040.
The free descriptor queue 1014 accepts messages over the messaging network 1012 for returning the freed packet descriptors. Descriptors pointing to the packet data are sent to the Packet Ordering Engine (POE) 1040. The POE 1040, in turn, appends its own information to the front of the messages and forwards them to a host processor/processor core.
The packet data may be processed by certain specialized processing engines 1034. For example, checksumming or CRC processing may occur at engines 1034. These activities may be controlled based on instructions from the micro-cores in the micro-core parser 1028. In addition, CRC key hashing may be performed at block 1030, which provide a flow identifier to the RX descriptor generator 1032.
FIG. 11 shows a diagram of a micro-core architecture 1100 according to some embodiments. The micro-core architecture 1100 provides a framework that not only has a small silicon footprint, but also contains enough processing and expansion capability to support packet processing tasks. In some embodiments, the micro-core architecture 1100 is compliant with standard and/or well known specifications and instruction sets. For example, the micro-core architecture 1100 can be implemented to support the MIPS32 Release2 user space instruction set.
The micro-core architecture 1100 in some embodiments is a five pipe stage, single issue 32-bit processor unit 506, which supports CISC-style enhanced instructions that perform simple ALU functions directly on data stored in memory as well as register files, and can write processing result either to the register file or memory. The memory and registers include a general purpose register (GPR) 1104, as well as a RAM 1108 that may be incorporated either as part of the micro-core or external to the micro-core. The registers within the micro-core may be used to communicate information to the micro-core about the current incoming packet. The registers may also be used by the micro-core to communicate specific tasks for downstream hardware to conduct on the current packet. A memory mapped control register 1106 provides management and control functionality over the micro-core architecture 1100. In some embodiments, the control register 1106 and RAM 1108 are not located within the micro-core itself.
The data is copied into the GPR 1104 for processing by the execution unit 1106. In some embodiments, the data is divided into multiple segments, e.g., where a register of 128 bits is divided into four segments of 32 bits each. This implementation for the micro-core provides for very efficient processing, since the packet data can therefore be operated upon on a segment basis. If some portion of the data is needed, the micro-core only needs to read in the necessary segment(s), modify or operate upon just that portion of the data, and then write it back to memory. The micro-core operates over multiple stages, including (a) instruction fetch (IF); (b) instruction decode (ID); (c) register memory read (REG/MEM1); (d) execute/address generation (EXEC/AGN); and (e) memory writeback (WRB/MEM1).
FIG. 12 shows functional components of a micro-core 1202 when implemented within an ingress path subsystem, according to some embodiments. An instruction cache 1204 (e.g., a 4 KB cache) is employed to hold instructions for the micro-core 1202. One or more packet caches 1206 are employed to hold packet header data to be processed by the micro-core 1202. In some embodiments, two separate packet caches 1206 (e.g., 512 KB data caches) may be utilized to maintain a constant set of data ready to be processed by the micro-core 1202. A content addressable memory (CAM) 1208 (e.g., a 3 KB CAM) may be shared across multiple micro-cores 1202. The CAM 1208 may be used to implement a dependency list structure according to some embodiments; alternatively, the dependency list is implemented in a separate CAM (not shown). The micro-core 1202 may also be associated with a shared memory 1210 (e.g., 32 KB shared SRAM) and DCache 1212 (e.g., 512 KB DCache). The Shared RAM (1210) and the Shared CAM can be used to store state data, such as a forwarding table. The D-Cache (1212) is used to store local-variables, if they do not fit inside the GPR.
One or more output buffers 1214 may be used to hold the outputs from the micro-core 1202. These outputs include, for example, IP and TCP/IP flags that are sent to a CRC or checksum block. The output may also include a key that is sent to a hash logic unit. In addition, the micro-core 1202 may output information (e.g., a prepad, discard, or EOP) that is used by a RX descriptor generator to generate descriptors. The output can also be the destination for the message. The destination can be either a CPU (main host CPU) or can be a Transmit queue inside NAE. In case it is a transmit queue, then the packet will be sent out without host CPU intervention.
Therefore, what has been described is an improved approach for implementing a flexible parser for a networking system, where the parser includes one or more micro-cores to process packets in a networking system. The micro-cores of the parser read the packet headers, and perform any suitably programmed tasks upon those packets and packet headers.
wherein the corresponding column is configured to hold data identifying whether a given packet associated with the corresponding column creates dependencies for one or more other packets.
wherein bits in the bit vector identify an existence of a dependency.
3. The system of claim 1, wherein the memory comprises content addressable memory.
wherein the corresponding column holds data identifying whether a given packet associated with the corresponding column creates dependencies for one or more other packets.
6. The method of claim 5, wherein each bit of the bit vector corresponds to the dependency for a different packet.
adding a value in the corresponding row to indicate whether the packet has a dependency on another packet.
8. The method of claim 7, wherein the value comprises a bit vector with bit values that correspond to rows from among the set of rows associated with other micro-cores from among the plurality of micro-cores.
releasing the packet if the dependency is not identified.
10. The method of claim 9, wherein a bit vector in the row is checked to identify a value indicating the dependency.
wherein a value in the second row indicates a dependency of the second packet on the packet, and wherein release of the packet causes a value in the second row to be modified to indicate no further dependency on the packet.
12. The system of claim 1, wherein, based on the dependency list, the plurality of micro-cores is configured to release a later packet from among the packets from a flow after an earlier packet, from among the packets, from the flow has been processed.
Kuila, K. et al., U.S. Appl. No. 13/164,521, filed Jun. 20, 2011, entitled "Programmable Micro-Core Processors for Packet Parsing".
Office Action, dated Mar. 10, 2014, for U.S. Appl. No. 13/164,521, filed Jun. 20, 2011, 10 pages.
Office Action, dated May 13, 2013, for U.S. Appl. No. 13/164,521, filed Jun. 20, 2011, 6 pages.
Office Action, dated Sep. 25, 2013, for U.S. Appl. No. 13/164,521, filed Jun. 20, 2011, 9 pages.
U.S. Appl. No. 13/107,809, filed May 13, 2011, entitled "Implementing Integrated Networking Functions at Wire Speed".


Cancer survivor Torsten Koehler talks about his experience with his students as a teacher going through cancer. Quotes from his book "Love Your Nuts" are in bold.
When I was diagnosed with testicular cancer I decided to tell my students (age group 11 to 15 years old) because they would have found out anyway as soon as the side effects of chemotherapy kicked in, and I didn't want rumours or speculations spread in the school community.
Encounters with parents of the students were different than before the cancer diagnosis. As soon as we said hello I realized that he or she knew! After saying hello we were immediately lost for words. Nobody wanted to ask how I was because obviously everybody knew how I was and we (especially adults) don't handle these kind of situations very well. Students are just honest and if they ask "how are you?" these little ones mean it.
I met a 12 year old boy in the cancer clinic who had testicular cancer.
"I decided there and then that I would educate the pupils about cancer when the opportunity arose. I had to brief them, and warn them, because all my pupils were around this age.
"Yes, that's what I thought, too," I answered. Then I put my fingers into what was left of my hair, pulled a little and let the handful of hair float to the floor. I know it was a ghoulish start to a lesson but I immediately had everybody's attention, exactly as planned. Each of them had to be informed. None of them was to doze through this lesson.
There were boys and girls in my class. I was going to explain testicular cancer and breast cancer to them so that neither the boys nor the girls had reason to feel embarrassed. Or at least it would be equally embarrassing for both sexes. I told them everything: how I had noticed that something was wrong, how I had sperm frozen and about chemotherapy and its side-effects.
Soon thereafter, I turned into a depressed person and decided I had to resign because I couldn't cope with my work and life anymore. I decided to travel the world. I had done that before and hoped my zest for life would return if I did positive things. Do something for me. What kept me going until the end of the school year were the students and I quote my book: "I still dreaded the last day of school. Having to say goodbye to the pupils was really getting to me. I knew how honest they were. During the past year they had vividly shown me that life is fun, too. I recalled this joie de vivre when I felt bad. Children played, sang, skipped along, quarrelled and made up again, and they squealed with pleasure. That was life. I also wanted to do that again. To squeal with pleasure!
I'd been travelling the world for 2 years and often thought about the students. In between destinations, I worked on a campsite in Munich to earn some travel money again. The school had my Munich address and I received letters and post cards from my former students. What a nice feeling to know that I had touched their lives. I replied with post cards from the different countries I visited.
In 2006 a former student of mine invited me for coffee to thank me for talking about my cancer in class and raising awareness. Because of my lessons, he went to the doctor in time and is saved at the age of 16!
That alone makes it worth standing up for cancer and energizes me to talk balls!
Torsten grew up on a cattle farm in Namibia. He studied teaching and was a teacher and deputy principal for 15 years in Namibia. This 15-year span was interrupted three times in the years 1991, 1997/8 and 2006, when he did what he loves most – travelling through 45 countries on all the continents.
He has been a Cape Town, South Africa resident since 2007. At present he is following his passions – photography and design – after leaving the teaching profession in 2005. You can visit his website at www.love-your-nuts.com.


At his regular press briefing on October 9, Shen Danyang, the Chinese Ministry of Commerce spokesperson, said that a free trade agreement (FTA) between all BRICS countries – Brazil, Russia, India, China, and South Africa – would be "a significant form of practical cooperation."
He added that, by setting up an FTA, BRICS countries would be able, "through the opening of their markets, to remove tariff and non-tariff barriers, give play to their comparative advantages, and advance trade and investment liberalization between them."
Shen noted that China has not formally raised the issue for the BRICS economic and trade ministers meeting on October 13 in New Delhi, but that many experts have proposed an FTA as a means to "promote South-South cooperation on a global scale."


text:
Louis Piochelle − francuski bokser, uczestnik Letnich Igrzysk Olimpijskich 1908 w Londynie, mistrz Francji z roku 1919.

Na Letnich Igrzyskach Olimpijskich 1908 przegrał w ćwierćfinale z reprezentantem Wielkiej Brytanii Haroldem Franksem, nie zdobywając medalu.

Przypisy

Linki zewnętrzne

Francuscy bokserzy
Francuscy olimpijczycy
Uczestnicy Letnich Igrzysk Olimpijskich 1920
Urodzeni w 1888
Zmarli w 1939

redpajama_set_name: RedPajamaWikipedia


We have already informed you about leaked CGI image and an actual photo of T-Roc taken on the public streets without any camouflage. As its appearance is already covered and not mysterious as before, we are here now with more info about other stuff, purely because Tiguan is a huge sales success and we shouldn't predict anything less for 2019 Volkswagen T-Roc.
Smaller SUV segments generate quite a lot popularity in Europe as things like Nissan Qashqai or Renault Captur goes over 200k mark of sold units annually, so the T-Roc main market is quite obvious. US soil is not so fertile for small crossovers, and just last year VW representatives claimed that T-Roc is not intended for the US also. Then in March, this year announcement came from Wolfsburg that US will get its share of small VW SUV, but don't get excited as things are not so clear.
T-Roc is about to be manufactured in Portugal, making a sale in the US not wise from a financial point of view as the price would not differ much from one attached to Tiguan. That would mean that T-Roc is a smaller compact vehicle, while actual subcompact one is yet to arrive including the US as its target.
T-Roc and future smaller sibling, whatever name the company chooses for it, would share similar things under the hood. MQB platform is the obvious choice as it serves to almost everything what VW has, and in Europe, it will house engines from 1.0-liter to 2.0-liter displacement, though CUV that will lend in the US probably won't go below the 1.8-liter unit.
Mentioned platform should allow decent driving dynamics, as we saw with Golf and Audi A3, and actually, that is exactly the case as it was already proven.
More precisely would be on the gravel as journalists from Car and Driver actually had a chance to drive T-Roc prototype in South Africa's Kalahari desert. MQB platform proved its sublime quality as small SUV refused to be shaken by rough road even for a second and stood firmly till the end. The prototype was agile, easily controllable and denying you of the usual drawbacks attached to the higher roof.
Even gravel drifting is sorted out in a undemanding manner, and if prototype drove like that production version could just go better. Small SUVs that are actually fun and interesting to drive are not so common, and Mazda should be worried about this upcoming thing.
So far we know that 2019 Volkswagen T-Roc could put a smile on your face once on the road, we know that underpinnings are more than just decent and we know that it looks alluring on the outside for a Volkswagen. You can find more visual exciting things for sure, but they wouldn't allow being driven like that or presumably have the cabin as refined as its if it follows usual brand's path.
So, no doubt that Europe is about to welcome another volume seller, and we will be here with more details as soon as it emerges.


Magyar aluminium fuel tank, Net capacity 13712 litres (4224; 2113; 3165; 4210), Nominal capacity 13000 litres (4000; 2000; 3000; 4000), 4 Compartments, Alfons Haar pump, Alma digital counter, Hose reel, Test pressure 0.32 bar, Max. working pressure 0.12 bar, Wall thickness 4 mm (rear head and shell), 6.33 mm (front head), ADR tank code LGBF // Truck Euro 4, AdBlue, Diff. lock, Traction control, Manual gearbox (8-speed), Tyres 315/70R22.5, Day cabin, Digital tacho, Air conditioning, Shipment dimensions 730x250x310 cm.


30 fellows from across Europe met in Berlin in May to ponder a new European civics. Their shared conviction was that several key national challenges in Europe, as well as our responses to these challenges, have cross-border causes and consequences. We discussed prospects of inclusive economic growth and the trends around inequality. Daniel Gros argued that short prospects were better than generally assumed, but added that Europe did have a long term growth challenge. Branko Milanovic demonstrated that the winners of the last 20 years were the global elite and the global middle class, but its losers was the Western middle class. Ivan Krastev tied multiple treads, including these economic ones, into a compelling account of origins of populism in Europe. His argument was that emergence of populism was less worrisome than the inability of the anti-populism sentiment to materialize. The group of course discussed migration: Grete Brochman outlined what a health debate and policy around migration may look like, and Claus Offe confirmed that we can and we should approach migration with courage and conviction. To round all these discussions, we considered with Kalypso Nicolaides what teleology of Europe would serve us best. Nathalie Tocci set us up with the latest thinking about Europe's role in the world.
Fellows are now working on synthesizing their views and analysis into a report. Our next and final stop is Strasbourg, where we will see whether we can respond to Secretary General Jagland's challenge of more reflection, less reaction and a better conversation.


text:
The Ford Mustang Mach-E Is Not Built for Sustained Track Performance
It may bear the Mustang name, but don't get any grand ideas on hot lapping your Mach-E.
By Mack Hogan
When Porsche launched its first electric car, the company made clear that it had prioritized sustained performance over extended periods of hard usage. Ford is making its position equally clear: the Mustang Mach-E was not built with sustained performance as one of its goals.
That's what Dave Pericak, Ford's global director of icons that headed up the Mach-E's development, told us when asked if the car could handle one or more laps at the Nürburgring. When pressed further, Ford's global EV communications manager Emma Bergg had a simple response: it's an SUV. And she's right, that's not usually priority one for SUV buyers.
Neither are burnouts. We got mixed answers on whether traction control could be fully defeated: a yes from Pericak, followed by no from Chief Program Engineer Ron Heiser, followed by a final answer from Pericak that the team would be making changes before the final release next year. But that left a broader question. If it's not for the track, if it might not rip burnouts, if it's available with all-wheel drive, if it's a four-door, if it's electric, and if it's a crossover, then what exactly links the Mach-E to the Mustang brand?
Because while the Mustang stands for accessible performance and fun, Ford has had a lot accessible performance cars that aren't Mustangs. The Focus RS, for instance, shares an engine with the Mustang EcoBoost High-Performance Pack, which is more than the Mach-E shares with any current Mustang coupe. It was also cheaper than the Mustang Mach-E, as were the Fiesta ST and Focus ST. They're not Mustangs, though.
So if it's not cheap performance nor form factor nor driven wheels nor power source that makes a Mustang, it's not immediately apparent what does. What the Mustang means, Pericak said, is hard to define directly.
"It's hard to put words to, but we know when we do it right," Pericak said. According to him, there's a soul and a holistic experience that defines the Mustang brand. It's not a faster version of a normal car, it's a performance product that has "the whole equation figured out."
But now that equation has new variables. And he'll openly admit that to solve it, you're going to have to make compromises. He noted that there are "inherent limitations in the silhouette of the car" that made development harder. An electric platform can lower the center of gravity on an EV crossover, but by definition it'll never be quite as low and sleek as a coupe or sedan could be.
As Pericak put it, "there's a reason that F1 cars don't look like SUVs."
What's important to point out — and Pericak did — is that the Mach-E is not supplanting Ford's mainstay pony car. Track-oriented buyers can still get a Shelby GT350R, burnout enthusiasts will always gobble up GTs, and autocross fanatics can still order an EcoBoost High-Performance Package.
This car likely won't be bought by people deciding between it and a GT500. Instead, the Mach-E is for fans of the Mustang brand — current owners or otherwise — that want to get a new, exciting experience. Those buyers don't care about Nürburgring times and, frankly, the Mach-E is far from the first Mustang that isn't built for abuse on a race track.
The Mustang, Pericak concluded, is about more than just accessible performance. It has to be rooted in authenticity. It wouldn't be authentic if they made their electric car exactly like the internal-combustion versions that came before it, just like he says it wouldn't be authentic to put fake vents on a Mustang. And though we were quick to point out that the textured front plastic bit on the Mach-E GT certainly looks like a fake grille, Pericak's larger point was clear.
It was created by Mustang engineers to drive like a Mustang. Since it can deliver that — the intangible Mustang soul Pericak describes — he says it's a true Mustang. Until we drive a finished version, we can't say if that's the honest-to-God truth or just marketing speak.
More From New Cars
Acura Integra Prototype Photos
The 2022 Nissan Pathfinder: Legends Never Die
Created for Created for Created by Hearst Autos for
Grid Legends Is a New Docuseries-Inspired Game
2022 Audi RS3 Photos
21 New Cars That Make Crazy Horsepower Per Liter
Jeep Gives the Wrangler 35-Inch Tires, 4.88 Gears
New EV Hummer Will Weigh as Much as Four Miatas
The Porsche Boxster GTS 4.0 Is Basically Perfect
The Flying Spur V-8 Is a Real Bentley
God Help Me, I Love Honda's Automatic Motorcycle

redpajama_set_name: RedPajamaCommonCrawl


text:
Matthews International Corporation
NasdaqGS:MATW Stock Report
View Valuation
Matthews International Future Growth
How is Matthews International forecast to perform in the next 1 to 3 years based on estimates from 2 analysts?
Future Growth Score
Future Growth Score 3/6
Earnings vs Savings Rate
Earnings vs Market
High Growth Earnings
Revenue vs Market
High Growth Revenue
Future ROE
Forecasted annual earnings growth
Earnings and Revenue Growth Forecasts
NasdaqGS:MATW - Analysts future estimates and past financials data (USD Millions)
Cash from Op
Avg. No. Analysts
9/30/2024 1,889 50 N/A 98 2
12/31/2022 1,773 -76 57 118 N/A
9/30/2022 1,762 -100 66 127 N/A
6/30/2022 1,744 -22 90 140 N/A
9/30/2021 1,671 3 128 163 N/A
6/30/2021 1,631 14 130 164 N/A
12/31/2020 1,520 -78 178 210 N/A
9/30/2020 1,498 -87 146 180 N/A
6/30/2020 1,492 -166 134 165 N/A
3/31/2019 1,585 73 96 137 N/A
12/31/2018 1,607 75 108 148 N/A
9/30/2018 1,603 107 104 148 N/A
12/31/2017 1,536 99 89 141 N/A
9/30/2016 1,480 67 N/A 140 N/A
Analyst Future Growth Forecasts
Earnings vs Savings Rate: MATW is forecast to become profitable over the next 3 years, which is considered faster growth than the savings rate (2%).
Earnings vs Market: MATW is forecast to become profitable over the next 3 years, which is considered above average market growth.
High Growth Earnings: MATW is expected to become profitable in the next 3 years.
Revenue vs Market: MATW's revenue (3.4% per year) is forecast to grow slower than the US market (6.9% per year).
High Growth Revenue: MATW's revenue (3.4% per year) is forecast to grow slower than 20% per year.
Earnings per Share Growth Forecasts
Future Return on Equity
Future ROE: Insufficient data to determine if MATW's Return on Equity is forecast to be high in 3 years time
Discover growth companies
High growth companies in the Commercial Services industry.
View Past Performance


text:
Tracking across devices with new Google Analytics
By Ashley Burgess	 February 4th 2013 17:07
At the end of 2012, Google introduced some genuinely cool changes to its Analytics products.
These were the kind of changes that get whoops from the audience when announced at the Google event in California (although in the UK the reception was predictably more… British).
The big thing is a new tracking method: user-centric, multi-sessional, multi-device tracking…
Google is taking Google Analytics (GA) in a new direction, focusing on making analytics more relevant to marketers – the people making decisions about budgets – than to just analysts and webmasters. GA took as its starting point the questions that marketers have been asking of their data for years. Additionally they are making the technology simpler to install and debug.
The big thing is a new tracking method: user-centric, multi-sessional, multi-device tracking. When I talked about this at Google recently, I used Viv, our client services team leader at Periscopix, to illustrate what the changes mean.
Viv's favourite website is Etsy. She recently bought a brass lobster from there, apparently this lobster serves no actual practical purpose, but that's another story. Her journey to that purchase might have looked like this:
Viv started by searching for Etsy on her work laptop; she browsed the site, and then registered with Etsy for updates on relevant offers.
On her train home, she checked the brass lobster on her iPhone.
When she got home, she got out her new iPad to have a final look (everything, even brass lobsters look better on an iPad) and made the purchase.
That's great for Etsy, which was able to provide all the right browsing experiences for Viv to make her decision. But if I was an analyst, or a marketer at Etsy, Viv is a nightmare; I wouldn't be able to get a full picture of what she's doing.
I'd know she started with a Google search for Etsy, browsed the site and registered. And even though she logged in on her iPhone and iPad using her unique registration number (and would then be given a new logged in user ID, that's not personally identifiable), I wouldn't be able to connect those actions. I'd see her as three separate users on three separate devices.
That's not very useful for Etsy. In this instance, they would have learned that iPad users are brilliant and spend lots of money, and that desktop/laptop users don't spend anything.
The keyword she used originally would have received zero credit and the sale would have been attributed most like to a brand term or direct visit, and yet Viv's journey started with a search, on a laptop.
It would, in effect, look something like this:
But there are obviously things that are common across each device that you could connect, in order to see that those three visits are from the same person, and that's exactly what GA is doing.
It 'stitches' the logged in user ID to the original unique user ID, and the purchase to the logged in user ID. The end result is that we can now see one user using three devices and making a purchase.
Now we have something more joined up, like the below:
This is dynamite for anyone with a transactional website, or a site that requires a registration or login interaction, so you can understand the true user journey.
Google have realised how many practical applications there are for this. For example, it will be possible to stitch online and offline purchase. If you want to buy a sofa, you might research it online, but you'll probably want to go and sit in it, and bounce up and down to try it out.
Now, you connect the online research with a customer purchase in the shop, if you have (for example) a loyalty card, or customer number, or postcode – anything that can tie that customer to the website activity.
That has implications for attribution, too. For example: Superdrug has a loyalty card. Let's say Viv looks at nail varnish online, but wants to buy next time she's in town.
So if she browses online, then buys offline, that offline purchase could be tied to the online activity – such as a search - that initiated the offline sale. . Good news if you are running a PPC campaign for Superdrug.
In the same launch we learned of so many other exciting new Google Analytics features that should keep us in the world of web analytics very busy for the next 12 months. Think what we can do with free attribution modelling for all, inter-session analysis, sequential intra-session analysis, data imports. The list goes on…
All this is based on a much-simplified tracking system, which makes tracking a lot easier to manage and to spot (and fix) issues, with a reduction in cookies from at least three down to one. Ultimately, this means that you'll spend less time paying people to fix problems, and more time on proper analysis that will improve the effectiveness of your marketing.
Blog Attribution Google Analytics multi-device tracking Periscopix PPC
Yahoo turns to Google for ads: sign of a new friendship?
When Yahoo recruited Marissa Mayer from Google to replace interim CEO Ross Levinsohn, some suggested that Mayer's departure from Google was an indication that she had reached her limit for advancement at the search giant, and that her role at Google was actually not as important as it might have seemed.
Whether the rumors about Mayer's status at Google were accurate or not, one thing was certain: Yahoo was placing a huge bet on the 30-something executive, one that might have been the last such bet it could make.
February 7th 2013 07:05
Blog Content marketing
71% of businesses plan to increase digital marketing budgets this year: report
Almost three out of four businesses (71%) plan to increase their digital marketing budgets this year, according to stats included in the new Econsultancy/Responsys Marketing Budgets 2013 Report.
In comparison only 20% of respondents said they plan to increase their traditional (offline) budgets, up slightly from 16% last year.
The average expected increase (for those increasing digital budgets) is 28%, slightly higher than the average expected increase of 26% for offline budgets.
January 25th 2013 14:45
Blog Multichannel Marketing
Research: Digital marketing is quickly coming of age in Australia
Econsultancy's annual report, the State of Digital Marketing in Australia, produced in association with Marketing Magazine, has found that the industry is continuing to develop at a rapid pace.
Investment in digital remains high, alongside an increased focus on measurement, attribution and channel accountability.


text:
Stephen Gerard Palombo – Major, United States Marine Corps
Reservists remembered for devotion to duty and country, love of flying
Families of the four Marine reservists killed in an apparent midair collision say they take comfort from knowing the men died flying in the line of duty.
Heather Rand, 29, says Captain David Clarke Cross, 34, gladly left behind his beloved Harley-Davidson for the mission.
One was a tough guy who melted when his son arrived.
One was a motorcycle-riding patriot who looked forward to doing his part in war, if it came.
One was a squadron commander who enjoyed juggling his civilian and military jobs.
And one postponed a family in order to achieve his goal to fly.
Brought together by their commitment to the military, the four Marine Corps reservists, killed Wednesday in an apparent midair collision, leave behind grieving families who said yesterday that, despite their tears, they take comfort from knowing the reservists died flying in the line of duty.
Marines begin probe of crash
The crash happened while the Camp Pendleton-based reservists were on a night reconnaissance flight in Texas for a U.S. Border Patrol anti-drug mission. A detachment of 53 Marines from Marine Light Attack Helicopter Squadron 775 were participating. The unit will return home this weekend, officials have said.
Major Steven G. Palombo, 36, wears a serious expression in many photos adorning his Carlsbad apartment, where his wife, Hiroko, swings between smiles and tears as she talks about him. Married in 1992, they have a 2-year-old son, Cameron.
Behind the stern looks, there was a big heart, said Palombo, who is 36.
"I want everyone to know my husband was a wonderful guy," she said, adding that she tells the girls at the school where she works as a student adviser to find a fellow like him.
"When we had a baby, nobody really expected Steven was going to be this sweet daddy. He's a big guy and tough-looking," Palombo said. "But he just loves Cameron. When people see Steven spending time with Cameron, you just find yourself smiling."
Palombo and the others were flying in two AH-1W Super Cobras, which are two-seater gunships. They departed Jan. 17 for a two-week mission with a Pentagon task force that assists civilian law enforcement agencies.
Camp Pendleton will salute the pilots with a private memorial service Wednesday on base.
Captain David Clarke Cross, 34, gladly left behind his beloved Harley-Davidson for the mission, said longtime girlfriend Heather Rand. The two lived in Carlsbad.
"He didn't understand how somebody couldn't be patriotic for this country," said Rand, who recalled how Cross sometimes wore a star-spangled bandanna when he rode his bike.
Cross "was actually looking forward to possibly going to war, if that was the decision that President Bush made," she said. "He wanted to do his part for this country."
He did most things with a gung-ho spirit, Rand said. "Every person he talked to, he made them feel that they were really great, and so he attracted a lot of people."
Cross will be buried in Virginia's Arlington National Cemetery with military honors.
Lieutenant Colonel Robert J. Theilmann, 47, who lived in Oceanside, saw his duties as squadron commander increase after Sept. 11, 2001, when reservists were called on more than before. He embraced the additional duties, said his older brother, Richard Theilmann of Queens, New York.
"I know some reservists had difficulty integrating their business and private life with all the additional call-up," Theilmann said. "He was able to juggle both family and work. He really was able to juggle all those balls in the air and keep things going."
Robert Theilmann, the squadron commander, served as chief executive of his son's heating and air-conditioning company. He also raised Shetland sheepdogs, his brother said. He and his wife of 20 years, Barbara, also bought and rehabilitated homes.
"You guys lost a fine citizen," Richard Theilmann said.
Major John M. Walsh, 36, had just bought a new condominium in San Marcos. A single man, he already had filled his garage with mountain bike, surf board, backpack and a bulletin-board full of entry numbers from road races he completed.
Walsh was full of life, said his father, Larry Walsh, of Palm Springs, and flying was his love.
"He had wanted to be a fighter pilot since he was 8 years old," Walsh said. "He had goals and he accomplished them. That's one of the reasons he wasn't married. He was focused on what he wanted."
After leaving active duty, he got a master's of business administration at the University of San Diego and worked as a project manager for a Poway electronics firm, in addition to his reservist duties.
He will be buried at Fort Rosecrans National Cemetery in Point Loma.
Everyone echoed the thoughts of Rand, who said she takes solace knowing Cross went down flying.
"I'm just happy he died doing that. If he were to die, I'm glad it was that, because he loved flying," she said.
Some said they looked forward to the results of a Marine investigation into the cause. Others didn't.
"They will probably put blame on somebody, but I don't care about that," Walsh said. "They were all experienced pilots. They were all doing the best they could."
But Palombo wants to find out all she can.
"I want to know a lot because I have to tell his son, when he's ready," she said. "When Cameron's old enough, I have to tell him everything about his dad."
STATE COLLEGE – A State College Area High School and Penn State graduate who died in a military helicopter crash was remembered Friday as a dedicated Marine who loved to fly helicopters and as his younger brother's hero.
David Cross, 34, was one of four Marine reservists killed when two helicopters collided Wednesday night during an anti-drug patrol along the Texas-Mexico border. He was a 1987 graduate of State College Area High School and a 1991 graduate of Penn State, his family said.
"My brother was a great guy," Dan Cross, 26, a student at Columbia University, said Friday evening from New York. "I know that might sound contrite. But it's the truth. He was always there for me.
"He was my big brother," said Dan Cross, also a State High alumnus, "and, in a lot of ways, he was my hero."
"He did love to fly," David Cross's father, also David Cross, said Friday from his home in Reston, Virginia. "Throughout his career, he kept taking assignments that were flying assignments."
David Cross was born in Washington, D.C., and grew up in Norfolk, Virginia. The Cross family moved to State College in 1986, when the father took a job at Raytheon.
David Cross enlisted in the Marines after enrolling at Penn State, where he was a member of Pi Kappa Alpha fraternity, his father said.
"He really got serious about his schooling at that time," his father said. "From then on, he did really well."
After graduating from Penn State in 1991, Cross entered officer-training school.
"That's where, David told me, he learned to sleep in the mud," his father said.
David Cross subsequently secured one of 10 slots to enter the Navy's air school in Pensacola, Fla. He later trained to fly Cobra helicopters at the Marine Corps' Camp Pendleton in California.
"Flying was what he wanted to do," said Kathy McClintic, David's stepsister, who works at Penn State's Applied Research Laboratory. "It was kind of his dream."
David Cross also leaves behind his mother, Gwynn Cross, of San Antonio; his step-mother, Linda Cross, of Reston; and his girlfriend, Heather Rand, of Carlsbad, Calif.
"He overcame a lot of adversity," Dan Cross said. "When he decided to become a pilot, they told him there was a 1 percent chance of him making it. But he really worked to make his dream happen."
In October 2002, David Cross left active duty and a career that had taken him to Japan, Russia and the Persian Gulf. He joined the Marine Corps Reserves and was working toward a career as a commercial pilot, his father said.
The elder David Cross, who now works at Lockheed Martin in Virginia, said his son will be buried at Arlington National Cemetery will full military honors. A memorial service will be held next week at Camp Pendleton for all four pilots who were killed.
As an investigation into the crash continued Friday, security was tight at a remote state park near the Rio Grande where witnesses reported seeing the two AH-1W Super Cobra helicopters collide, according to wire service reports.
The victims were members of Marine Light Attack Helicopter Squadron 775. The detachment of six helicopters and 53 Marines, deployed to Laredo, Texas, on Jan. 17, has been ordered to return to Camp Pendleton, the Marine Forces Reserves said.
Dan Cross said his brother was heading up the Texas mission and was piloting one of the Cobras when the crash occurred.
"I'm not sure what happened down in Texas," Dan Cross said. "But he was a good pilot."
Crash kills 4 reservists from Pendleton
The collision of two Super Cobra helicopters came during a drug interdiction flight
The Orange County Register
Two Marine helicopters slammed into each other late Wednesday (22 January 2003) during a nighttime counter-drug operation near the U.S.-Mexico border, killing four Camp Pendleton- based reserve aviators, officials said.
The AH-1W Super Cobra helicopters collided near Zapata, Texas, about 9:30 p.m., lighting up the sky with fiery wreckage, witnesses said.
The cause of the collision is under investigation.
The aviators were wearing night-vision goggles and infrared sensors, but it is unclear what role, if any, the devices played in the crash.
The men, assigned to Marine Light Attack Helicopter Squadron 775, were identified as:
Lieutenant Colonel Robert J. "Ramrod" Theilmann, 47, a Pendleton flight instructor and commander of the 300-member squadron, dubbed "the Coyotes."
Major Steven G. Palombo, 36, whose wife just gave birth to a daughter.
Captain David C. "Moon Pie" Cross, 34, who remained active in the Marines because he couldn't find a job flying commercial airliners.
Major John W. Walsh, 36, another expert pilot.
All lived in San Diego County.
"This is a huge loss to our family," said Sergeant Major Robert Gallagher, a reservist with the Coyotes and a Fountain Valley police detective. "Our squadron has received numerous awards for safety, which makes all of this incredibly ironic."
The two-seat Super Cobra attack helicopters have a good safety record, having served in combat during the Persian Gulf War, experts said.
The four Marines had been deployed to work with Joint Task Force Six, a military/law enforcement drug interdiction team.
It was not the first fatal crash involving the task force. In 1995, an Army pilot was killed during a similar surveillance mission in Arizona. Defense officials say a door on the pilot's OH-58C helicopter came off and he lost control of the aircraft. That crash also occurred after dark.
Organized in 1989, the task force teams military resources with local and federal law enforcement to stop drug smugglers.
Dozens of the group's missions were worked by reservists from the Pendleton-based squadron. Never before have the Coyotes lost a Marine.
Theilmann had been a pilot for more than 20 years and worked as a Cobra flight instructor.
"He was pretty much a military-career kind of person," said his wife, Barbara. "He wanted to fly. He died doing something he wanted to do. If there's any way a pilot can go, this is it."
Barbara Theilmann said she always tried not to think about how dangerous her husband's job was.
"There's a lot of things the military does on a daily basis, and no one's aware that they're involved in," she said. "Families get left behind. It doesn't take a war."
Funeral arrangements are pending, but Barbara Theilmann, who spoke of her husband in the present tense, said he wanted a full-dress sendoff.
"He's such a military person, he wants to have the full military funeral, complete with full colors and a flyby of Cobras in the missing-man formation," she said.
Cross joined the Marines after graduating from Penn State University because he always wanted to fly.
"He's a pilot and always wanted to be a pilot," said his father, David Cross of Reston, Virginia. "He actually left the Marines last year because he wanted to be a commercial pilot, but it was just not good timing, so he went back on active duty. He loved to fly. He did what he could to keep flying."
The aviator lived in Carlsbad with his girlfriend, Heather Rand, his father said, and will be buried at Arlington National Cemetery.
Walsh's family could not be reached for comment.
Palombo's wife, who recently had a baby girl, was too distraught to talk at length about her husband, who lived in Carlsbad.
"I want everybody to know how good my husband was," Hiroko Palombo said. "But I just can't right now."
E-Mail: 8 August 2003:
As I reviewed your site today, I noticed an incorrect callsign for Captain David C. Cross. His callsign is posted as "Munpi", but it is in fact "Moon Pie."
Captain Cross was one of my best friends and we served in the same Squadron together many years ago, when he was given the callsign Moon Pie.
Your site and information was very well done otherwise.
Please feel free to contact me with any questions. Thank you for your time.
Very Respectfully, Major Dean Putnam, USMC H-1
Upgrades Operational Test Director
Marine Helicopter Squadron One (HMX-1) NAS Patuxent River
Wreckage from a Wednesday night collision between two military helicopters is strewn over dusty scrubland near the Mexican border in Falcon Heights, Texas. All four Marine reservists aboard died.
COBRA FACTS
The Super Cobra is a day/night marginal-weather attack helicopter. During the Persian Gulf War, says the Marine Corps, these helicopters destroyed 97 tanks, 104 armored personnel carriers and vehicles, 16 bunkers, and 2 anti-aircraft artillery sites without the loss of any aircraft. Super Cobra's at-a-glance:
Primary function: attack helicopter
Length: 58 feet
Height: 13.7 feet
Rotor diameter: 48 feet
Speed: 169 mph
Range: 294 miles in basic combat configuation
Ceiling: 18,700 feet
Crew: 2 officers
Armament: One 20mm turreted cannon with 750 rounds; four external wing stations that can fire 2.75"/5.0" rockets and a wide variety of precision guided missiles, including TOW/Hellfire, Sidewinder and Sidearm missiles.
Introduction date: 1986
Unit replacement cost: $10 million
Manufacturer: Bell Helicopter Textron
Source: U.S. Marine Corps
CROSS, DAVID C., CAPT., USMC (Age 34)
Died on January 22, 2003, when his helicopter went down while on assignment assisting the U.S. Border Patrol along the U.S.-Mexican border in South Texas.
David was born in Washington, D.C. on October 11, 1968. He grew up in Alexandria, Virginia, and State College, Pennsylvania. He graduated from the Pennsylvania State University, was a member of the Pi Kappa Alpha Fraternity and held a second degree blackbelt in Tae Kwon Do.
David joined the Marine Corps in 1991 and trained as a Naval Aviator in Pensacola, Florida. After receiving his wings, he was transferred to Camp Pendleton in San Diego, California, where he flew and later became an instructor for the AH-1W Super Cobra Attack Helicopter.
He is survived by his mother, Gwynn A. (Dowell) Cross of San Antonio, Texas; his father, David C. Cross and stepmother, Linda L. Cross of Reston, Virginia; his brother, Daniel S. J. Cross of New York City; his long time girlfriend, Heather Rand of Carlsbad, California;aunts, uncles, cousins and many friends.
A visitation will be held at the ADAMS GREEN FUNERAL HOME, 721 Elden St., Herndon, Virginia, from 5 to 8 p.m. on February 4. A graveside service with Full Military Honors will be held at 9 a.m. on Wednesday, February 5 at Arlington National Cemetery.
Oh, I have slipped the surly bonds of earth and danced the skies on laughter, silvered wings; and while with silent lifting mind, I've trod the high untrespassed sanctity of space, put out my hand, and touched the face of God.
Author, John Gillespie Magee, Jr.
PALOMBO, STEVEN GERARD
MAJ US MARINE CORPS
VETERAN SERVICE DATES: 12/16/1985 – 01/22/2003
DATE OF INTERMENT: 03/06/2003
BURIED AT: SECTION 60 SITE 7898
United States Air Force Aircrew – 23 June 1969
Robert D. Bohn – Major General, United States Marine Corps


Allen, TX (September 6, 2018)—This summer, Kiddie Academy®, a nationally recognized provider of comprehensive educational child care programs, invites children and their parents to get excited about reading and enjoy its free Storytime LIVE! community event to celebrate the grand opening in Allen. Over the years, Curious George has delighted communities at hundreds of events all across the U.S., and this year, Kiddie Academy is thrilled to announce that Pinkalicious®, the whimsical and effervescent storybook character known for all things pink, will be joining Curious George. The Storytime LIVE! event will be held on September 15th from 10 a.m. to noon at Kiddie Academy of Allen, located at 1504 W. Exchange Parkway.
Attendees will have the chance to meet Curious George and Pinkalicious® as they come to life during book readings. The event will also feature a bounce house obstacle course, face painting, a balloon artist, refreshments and food. To reserve your spot to attend, please visit kiddieacademy.com/academies/allen.


Yellow Fishes is a premier Branding Agency that builds purposeful brands.
We are immensely passionate about defining and building brands. It fuels & drives us. We use the power of Brand Strategy and Brand Design to build meaningful brands. We believe Meaningful Branding has the power to inspire Human Behaviour. We build your brand in a way that's true to its Personality.
We believe that Aspiration is the "single-common denominator" across all cultures and societies. This informs every brand we build and every connection we make. It is not just our way of seeing the world, this is our Strategic Vision that guides how we build strong brands. And our Esoteric Name is the reflection of this profound vision.


text:
var getRoot             = require('./handlers/getRootHandler.js');
var getMailboxesByDep   = require('./handlers/getMailboxesByDepHandler.js');
var getMailboxesCount   = require('./handlers/getMailboxesCountHandler.js');
var postMailboxes       = require('./handlers/postMailboxesBulkHandler.js');

var config          = require('./serviceConfig.js');

var express         = require('express');
//var bodyParser      = require('body-parser')

/// Print out configuration info
console.log('DB.URL:   ' + config.DB.URL);
console.log('REST.URL: ' + config.REST.URL);

var app = express();

app.set('Title', 'RESTful service');
//app.use(bodyParser.json());
//app.use(bodyParser.urlencoded({extended: true}));

/// GET service root
app.get(getRoot.spec.path, getRoot.action);

/// GET return mailboxes
app.get(getMailboxesByDep.spec.path, getMailboxesByDep.action);

/// GET return mailboxes
app.get(getMailboxesCount.spec.path, getMailboxesCount.action);

/// POST add a lot of mailboxes
app.post(postMailboxes.spec.path, postMailboxes.action);

try
{
	app.listen(config.REST.Port);
}
catch(ex)
{
	console.error(ex);
}

console.log('Started REST service');

redpajama_set_name: RedPajamaGithub


text:
Survey of Israel o Departamento Topográfico de Israel (Hebreo: מפ"י - המרכז למיפוי ישראל) es el departamento topográfico y cartográfico  del Ministerio de Construcción y Vivienda de Israel. Es el sucesor del Departamento Topográfico de Palestina, establecido por el Mandato Británico en 1920.

Historia

El Mandato británico estableció el primer departamento topográfico del país en 1920, conocido como Survey of Palestine. En 1930, se levantó un edificio para alojar al departamento en el extremo sur de un terreo de 30 acres cerca del cementerio templario alemán en Tel Aviv. Durante la Segunda Guerra Mundial, fue usado por el ejército británico

Hoy día, la oficina principal del departamento está situada en Tel Aviv con sucursales en Jerusalén, Beerseba, Haifa y Nazaret.

Responsabilidades del departamento

El departamento es la agencia del gobierno para cartografiar, geodesia, catastro y proceso geográfico informático. Es responsable de la infraestructura nacional es estas áreas, así como de otras funciones.

Respecto a la geodesia, el departamento opera como Instituto Nacional Geodésico, adoptando la referencia elipsoide, desarrollando y manteniendo la red de control geodésico, definiendo la información nacional horizontal y vertical, estableciendo la proyección adecuada acompañada con as ecuaciones y transformaciones cartográficas, de aplicación en cartografía, catastro y proceso informático de geodesia.

En el área de catastro, el departamento dirige las actividades de registro de la tierra (Departamento de catastro y tierras).  El registro de los derechos de tierras está basado en los principios de Torrens, que en efecto proporciona una garantía del estado de los derechos registrados. El departamento es responsable de definir los límites de bloques y parcelas demarcando sus coordenadas y planos. Todos estos procedimientos están amparados en la normativa topográfica. El 95 % del área del país ha tenido procesos de asentamientos. Toda esta área está subdividida aproximadamente en 15.000 bloques y 800.000 parcelas. El departamento trata cada año con el asentamiento y también con nuevas subdivisiones (reparcelación) que supongan cambio en los derechos de las tierras, en su uso o en ambos.

El departamento topográfico de Israel es la Agencia Nacional Cartográfica, responsable de definir los mapas requeridos, con especial atención a la  de infraestructuras de construcción, seguridad, servicios de emergencia, protección del medio ambiente, turismo, investigación y desarrollo.

Estas tareas requieren el establecimiento de unos estándares, redes de coordenadas, incluyendo especificaciones de proyecciones cartográficas, estándares de precisión, práctica de toponimia y símbolos.

El la serie de mapas estándar ahora es el 1:50.000, del que se derivan las series 1:100.000. Las ediciones actuales de estas series fueron producidas por medios analógicos y revisadas por medios digitales. Además se han creado un número de mapas 1:25.000, todos basados en los archivos del Sistema de Información  Geográfica Nacional, gestionados por el departamento. Sería apropiado decir que todas las series de mapas están en proceso de transición a un sistema cartográfico de proceso digital. Otros productos dignos de mención son planos de ciudades y el Atlas de Israel, siendo producidos en cooperación con la Universidad Hebrea de Jerusalén.

Los asuntos de geoinformática ha sido confiados al departamento por decisión del gobierno de 1990 y 1993, designando al departamento como responsable de la base de datos del  Sistema de Información Geográfica Nacional, incluyendo un conjunto uniforme de códigos para asegurar la compatibilidad y foro interministerial, que es una plataforma de discusión y planteamientos políticos.

El Servicio de Información Geográfica Nacional incluye una base de datos topográfica a escala 1:40.000, revisada periódicamente. La base de datos consiste en 10 capas de datos con sus códigos apropiados. Existe también una base de datos catastral, basada en los planos y mapas catastrales. Se suele proporcionar información y gestionar operaciones en el catastro, pero no tienen estatus legal del mismo modo que los documentos originales. Además existe una base de datos de direcciones de los mayores centros de población, gestionados en cooperación con la Oficina de Censo Nacional.

Primeros mapas detallados (década de 1950 a la de 1960) en escala 1:20.000

Referencias

 The Israeli Spatial data infrastructure. ISPRS 2010 at: http://www.isprs.org/proceedings/XXXVIII/4_8_2-W9/papers/final_232_ISPRS_SFB_030810-srebro-Felus-.pdf

Enlaces externos
 Survey Of Israel
 Survey Of Israel's Heritage website

Gobierno de Israel
Geografía de Israel
Sociedades geográficas
Cartografía
Israel
Topografía