• Refine Query
  • Source
  • Publication year
  • to
  • Language
  • 159
  • 75
  • Tagged with
  • 234
  • 234
  • 129
  • 105
  • 84
  • 81
  • 54
  • 54
  • 39
  • 36
  • 36
  • 30
  • 27
  • 27
  • 24
  • About
  • The Global ETD Search service is a free service for researchers to find electronic theses and dissertations. This service is provided by the Networked Digital Library of Theses and Dissertations.
    Our metadata is collected from universities around the world. If you manage a university/consortium/country archive and want to be added, details can be found on the NDLTD website.
51

Tuplebiz : um espaço de tuplas distribuido e com suporte a transações resilientes a falhas bizantinas / Tuplebiz: a distributed tuple space resilient to byzantine faults

Souza, Gisele Pinheiro January 2012 (has links)
Os modelos de coordenação de comunicação possibilitam a cooperação entre os diversos processos que fazem parte de um sistema distribuído. O modelo de coordenação de espaço de dados compartilhado, o qual é representado pelo espaço de tuplas, permite que a comunicação tenha tanto desacoplamento referencial quanto temporal. Devido essas características, o espaço de tuplas é frequentemente usado em aplicações pervasivas e paralelas. A habilidade de tolerar a falhas é importante para ambos os tipos de aplicações. Para aplicações pervasivas na área médica, uma falha pode custar vidas. Nesse contexto, esse trabalho propõe o Tuplebiz, um espaço de tuplas distribuído que suporta transações em um ambiente sujeito a falhas bizantinas. As falhas bizantinas encapsulam uma variedade de comportamentos faltosos que podem ocorrer no sistema. O Tuplebiz é dividido em partições de dados para facilitar a distribuição entre diferentes servidores. Cada partição garante tolerância a falhas por meio de replicação de máquina de estados. Adicionalmente, o Tuplebiz também provê transações que possuem as propriedades ACID, isto é, as propriedades de atomicidade, consistência, isolamento e durabilidade. O gerente de transações é responsável por garantir o isolamento das transações. Testes de desempenho e injeção de falhas foram realizados. A latência do Tuplebiz sem falhas é aproximadamente 2,8 vezes maior que a latência de um sistema não replicado. Os testes de injeção tiveram como base um framework de testes de injeção de falhas para sistemas tolerantes a falhas bizantinas. Os testes avaliaram os seguintes tipos de falha: mensagens perdidas, atrasos de envio de mensagens, corrupção de mensagens, suspensão do sistema e crash. A latência no caso de falhas foi maior que no caso sem falhas, mas todas as falhas foram suportadas pelo Tuplebiz. Como estudo de caso, é revisada a integração do Tuplebiz com a Guaraná, uma linguagem específica de domínio usada para modelar soluções de integração de sistemas. As tarefas de uma solução de integração na Guaraná são centralizadas atualmente. A proposta de integração prevê a distribuição das tarefas entre diferentes servidores. / The coordination models enable the communication among the process in a distributed system. The shared data model is time and referential decoupled, which is represented by tuple spaces. For this reason, the tuple space is used by parallel and pervasive applications. The fault tolerance is very important for both type of application. For healthcare applications, the fault can cost a life. In this context, this work introduces the Tuplebiz, a distributed tuple space that supports transactions in environment where byzantine faults can occur. Byzantine faults include many types of system faults. The Tuplebiz is spitted in partitions. The main idea behind it is to distribute the tuple space among servers. Each partition guarantees the fault tolerance by using state machine replication. Furthermore, Tuplebiz has transaction support, which follows the ACID properties (atomicity, consistency, isolation, durability). The transaction manager is responsible for maintaining the isolation. Performance and fault injection tests were made in order to evaluate the Tuplebiz. The Tuplebiz latency is approximately 2.8 times bigger than the one for a non replicated system. The injection tests were based on an injection fault framework for byzantine faults. The tests applied were: lost message, delay message, corrupted message, system suspension and crash. The latency was worst on those cases; however the Tuplebiz was able to deal with all of them. Also, a case is presented. This case shows the integration between Tuplebiz and Guaraná, which is a domain specific language, used for designing Enterprise Application Integration applications. The solution integration tasks are centralized nowadays. The integration approach aims to distribute the tasks among servers.
52

Desenvolvimento e teste de um monitor de barramento I2C para proteção contra falhas transientes / Development and test of an I2C bus monitor for protection against transient faults

Carvalho, Vicente Bueno January 2016 (has links)
A comunicação entre circuitos integrados tem evoluído em desempenho e confiabilidade ao longo dos anos. Inicialmente os projetos utilizavam barramentos paralelos, onde existe a necessidade de uma grande quantidade de vias, utilizando muitos pinos de entrada e saída dos circuitos integrados resultando também em uma grande suscetibilidade a interferências eletromagnéticas (EMI) e descargas eletrostáticas (ESD). Na sequência, ficou claro que o modelo de barramento serial possuía ampla vantagem em relação ao predecessor, uma vez que este utiliza um menor número de vias, facilitando o processo de leiaute de placas, facilitando também a integridade de sinais possibilitando velocidades muito maiores apesar do menor número de vias. Este trabalho faz uma comparação entre os principais protocolos seriais de baixa e média velocidade. Nessa pesquisa, foram salientadas as características positivas e negativas de cada protocolo, e como resultado o enquadramento de cada um dos protocolos em um segmento de atuação mais apropriado. O objetivo deste trabalho é utilizar o resultado da análise comparativa dos protocolos seriais para propor um aparato de hardware capaz de suprir uma deficiência encontrada no protocolo serial I2C, amplamente utilizado na indústria, mas que possui restrições quando a aplicação necessita alta confiabilidade. O aparato, aqui chamado de Monitor de Barramento I2C, é capaz de verificar a integridade de dados, sinalizar métricas sobre a qualidade das comunicações, detectar falhas transitórias e erros permanentes no barramento e agir sobre os dispositivos conectados ao barramento para a recuperação de tais erros, evitando falhas. Foi desenvolvido um mecanismo de injeção de falhas para simular as falhas em dispositivos conectados ao barramento e, portanto, verificar a resposta do monitor. Resultados no PSoC5, da empresa Cypress, mostram que a solução proposta tem um baixo custo em termos de área e nenhum impacto no desempenho das comunicações. / The communication between integrated circuits has evolved in performance and reliability over the years. Initially projects used parallel buses, where there is a need for a large amount of wires, consuming many input and output pins of the integrated circuits resulting in a great susceptibility to electromagnetic interference (EMI) and electrostatic discharge (ESD). As a result, it became clear that the serial bus model had large advantage over predecessor, since it uses a smaller number of lanes, making the PCB layout process easier, which also facilitates the signal integrity allowing higher speeds despite fewer pathways. This work makes a comparison between the main low and medium speed serial protocols. The research has emphasized the positive and negative characteristics of each protocol, and as a result the framework of each of the protocols in a more appropriate market segment. The objective of this work is to use the results of comparative analysis of serial protocols to propose a hardware apparatus capable of filling a gap found in the I2C protocol, widely used in industry, but with limitations when the application requires high reliability. The apparatus, here called I2C Bus Monitor, is able to perform data integrity verification activities, to signalize metrics about the quality of communications, to detect transient faults and permanent errors on the bus and to act on the devices connected to the bus for the recovery of such errors avoiding failures. It was developed a fault injection mechanism to simulate faults in the devices connected to the bus and thus verify the monitor response. Results in the APSoC5 from Cypress show that the proposed solution has an extremely low cost overhead in terms of area and no performance impact in the communication.
53

Coping with permanent faults in NoCs by using adaptive strategies based on router design-level and routing algorithm-level / Cobrindo falhas permanentes em Redes intrachip usando técnicas adaptativas nos roteadores em um nível de projeto e em um nível de algoritmo

Concatto, Caroline Martins January 2009 (has links)
Hoje em dia, as redes intra chip (NoC) são cada vez mais utilizadas como uma arquitetura de comunicação alternativa para sistemas complexos, pois estas permitem flexibilidade e desempenho da comunicação. Porém, o grande número de interconexões da rede, aliado à diminuição das dimensões dos transistores fabricados nas tecnologias nanométricas, fazem com que a NoC possa ter um grande número de falhas durante sua fabricação, ou por desgaste durante sua vida útil. Sabe-se que, em futuras tecnologias os circuitos integrados terão uma taxa de falhas permanentes de 20 a 30%. Entretanto, mesmo na presença de falhas, é desejável que a NoC permaneça funcionando corretamente. A partir do diagnóstico das falhas, a NoC deve ser capaz de buscar alternativas para manter a comunicação entre os núcleos, evitando os canais e os roteadores com falhas. O objetivo deste trabalho é propor mecanismos adaptativos de proteção contra falhas permanentes. Mesmo quando são adicionados componentes extras para a substituição em SoCs, a ocorrência de falhas permanentes na rede intrachip impede a substituição ou reparo de um componente no sistema intrachip. Portanto a tolerância a falhas na NoC será crucial para reduzir custo de manufatura, e aumentar o rendimento e o tempo de vida do circuito integrado. O mecanismo proposto é capaz de evitar falhas sabendo anteriormente, na fase de teste e diagnóstico, a localização especifica da falha. Portanto, as técnicas se adaptam em cada roteador para evitar as falhas permanentes, sempre buscando manter desempenho, aumentar o rendimento e a confiabilidade do sistema. / Nowadays, networks-on-chip (NoCs) have been used as an alternative communication architecture inside complex system on-chip. They offer better scalability and performance than the traditional bus. However, the growing number of interconnects that have to be inserted using smaller transistors means that NoCs have a growing number of faults, either from manufacturing or due to aging. In future systems-on-chip (SoCs), the fault rate will be around 20 to 30% of the contact and transistors of integrated circuits. Therefore, even in the presence of a fault, it is still desirable that NoCs properly work. The main idea of this work is to implement adaptive mechanisms to protect NoCs against permanent faults. The main advantage of such mechanism is to manage failures based on data from the testing and diagnosing phase. The mechanisms are adapted in each router in order to sustain performance, increasing the system yield and reliability even in the presence of failures. Even if one adds extra blocks for replacement, the occurrence of permanent faults in a NoC might preclude the replacement or repair of a faulty component within the SoC. In such case, fault-tolerant NoCs are able to reduce manufacturing costs, increase yield and the lifetime of the chip.
54

Protocolo de recuperação por retorno, coordenado, não determinístico

Cechin, Sergio Luis January 2002 (has links)
O uso da recuperação de processos para obter sistemas computacionais tolerantes a falhas não é um assunto novo. Entretanto, a discussão de algoritmos para a recuperação em sistemas distribuídos, notadamente aqueles que se enquadram na categoria assíncrona, ainda encontra pontos em aberto. Este é o contexto do presente trabalho. Este trabalho apresenta um novo algoritmo de recuperação por retorno, em sistemas distribuídos. O algoritmo proposto é do tipo coordenado, e seus mecanismos componentes determinam que seja classificado como um algoritmo baseado em índices (index-based coordinated). Desta forma, a tolerância a falhas é obtida através do estabelecimento de linhas de recuperação, o que possibilita um retorno consideravelmente rápido, em caso de falha. Seu desenvolvimento foi feito com o objetivo de minimizar o impacto ao desempenho do sistema, tanto quando este estiver operando livre de falhas como quando ocorrerem as falhas. Além disso, os mecanismos componentes do algoritmo foram escolhidos visando facilitar a futura tarefa de implementação. A satisfação dos objetivos decorre principalmente de uma importante característica assegurada pelos mecanismos propostos no algoritmo: o não bloqueio da aplicação, enquanto é estabelecida uma nova linha de recuperação. Esta característica, associada ao rápido retorno, oferece uma solução promissora, em termos de eficiência, para a recuperação, um vez que o impacto no desempenho tende a ser reduzido, quando o sistema encontra-se operando em ambas condições: livre de erros ou sob falha. Diferentemente da maioria dos algoritmos coordenados encontrados na literatura, o algoritmo proposto neste trabalho trata as mensagens perdidas. A partir da análise das características das aplicações, bem como dos canais de comunicação, quando estes interagem com o algoritmo de recuperação, concluiu-se que os procedimentos usados para recuperação de processos devem prever o tratamento desta categoria de mensagens. Assim, o algoritmo proposto foi incrementado com um mecanismo para tratamento das mensagens que têm o potencial de tornarem-se perdidas, em caso de retorno, ou seja, evita a existência de mensagens perdidas. Uma das decisões tomadas durante o desenvolvimento do algoritmo foi a de permitir um processamento não determinístico. Na realidade, esta escolha visou o aumento do espectro das falhas que poderiam ser tratadas pela recuperação. Tradicionalmente, a recuperação por retorno é empregada para tolerar falhas temporárias. Entretanto, a diversidade de ambiente, freqüente nos SDs, também pode ser usada para tolerar algumas falhas permanentes. Para verificar a correção do algoritmo, decidiu-se empregar um formalismo existente. Assim, a lógica temporal de Lamport (TLA) foi usada na especificação dos mecanismos do algoritmo bem como em sua demonstração de correção. O tratamento referente às mensagens perdidas, atrav´es do uso de mensagens de resposta, associado com o uso de uma lógica temporal, levou à necessidade de rever os critérios de consistência. Esta revisão gerou um conjunto de fórmulas de consistência ajustadas à existência de mensagens de diferentes classes: mensagens da aplicação e mensagens de resposta.
55

FlexGroup: um ambiente flexível para comunicação em grupo

Rivera, Rodrigo Dias January 1999 (has links)
Mecanismos de comunicação entre processos são fundamentais no desenvolvimento de sistemas distribuídos, já que constituem o único meio de compartilhar dados entre processos que não dispõem de memória comum. Um dos principais mecanismos de comunicação utilizados é a troca de mensagens entre os processos componentes do sistema. Existem muitas aplicações que são compostas por um conjunto de processos que cooperam para realizar uma determinada tarefa e que são mais facilmente construídas se o sistema operacional oferecer a possibilidade de se enviar uma mensagem a diversos destinos. Neste caso são necessários mecanismos que permitam a difusão confiável de uma mensagem para um grupo de processos em uma única operação. Tendo em vista esta necessidade, diversos protocolos têm sido apresentados na literatura para permitir a comunicação entre um grupo de processos com diferentes graus de complexidade e de desempenho. Este trabalho apresenta um ambiente para desenvolvimento e utilização de protocolos de comunicação em grupo, denominado FlexGroup. O ambiente divide os protocolos em suas características fundamentais, permitindo que estas características possam ser desenvolvidas separadamente como subprotocolos. Os subprotocolo são interligados através de uma interface comum e gerenciados pelo núcleo do ambiente. A comunicação entre as diversas máquinas da rede é gerenciada pelo FlexGroup, permitindo que o desenvolvedor de um novo subprotocolo possa somente se focar nas características específicas do seu protocolo. Esta modularidade permite, ainda, que apenas as partes de interesse de um novo protocolo precisem ser implementadas, além de também viabilizar a criação de um protocolo baseado nos já existentes no ambiente. Além disso, o ambiente permite que as aplicações de comunicação em grupo possam definir, através de uma biblioteca, o conjunto de subprotocolos que desejam utilizar, em tempo de execução, sem necessidade de conhecer a implementação interna dos subprotocolos.. Da mesma forma, alguém que se proponha a realizar comparações com os protocolos existentes, pode utilizar os diversos subprotocolos e as aplicações existentes, bastando alterar os protocolos utilizados em tempo de execução e avaliando somente as características que deseje analisar.
56

Implementação de objetos replicados usando java

Ferreira Filho, Joao Carlos January 2000 (has links)
Este trabalho busca a implementação da replicação de objetos através da linguagem Java e de seu sistema de invocação remota de métodos (Remote Method Invocation - RMI). A partir deste sistema, define-se uma classe de replicação - a máquina de replicação – onde a implementação de grupos de objetos é estruturada de acordo com a arquitetura cliente/servidor, sendo o cliente o representante (a interface) de um grupo de objetos e os servidores representam os demais componentes do grupo. A classe de replicação atende a uma necessidade importante dos sistemas distribuídos - o desenvolvimento de aplicações tolerantes a falhas. Fundamentalmente, a tolerância a falhas é obtida por redundância e, no caso de mecanismos de tolerância a falhas por software, esta redundância significa basicamente replicação de dados, processos ou objetos. A tolerância a falhas para tal tipo de sistema é importante para garantir a transparência do mesmo, visto que, assim como um sistema distribuído pode auxiliar muito o usuário pelas facilidades oferecidas, o não cumprimento de suas atividades de acordo com o esperado pode, em algumas situações, causar-lhe transtornos e erros irrecuperáveis nas aplicações. Finalmente, como principal contribuição, este trabalho descreve e implementa a solução completa para a construção de uma biblioteca de classes que oferece a replicação de forma totalmente transparente para o usuário.
57

Sistema de controle de consumo para redes de computadores

Krolow, Roger al-Alam January 2000 (has links)
Este trabalho define e implementa um sistema de controle de consumo para redes de computadores, objetivando aumentar o tempo de operação da rede em caso de operação com recursos limitados e redução de consumo de energia em situações de fornecimento normal. Na definição do sistema, denominado NetPower, foi estabelecida uma estrutura através da qual um gerente (coordenador) monitora as atividades dos equipamentos vinculados à rede, e determina alterações nos estados de consumo respectivos, de acordo com as necessidades ou atendimento de padrões de otimização. Aos equipamentos podem ser atribuídos diferentes privilégios em uma hierarquia adaptável a diversos ambientes. Um reserva oferece opção às falhas do gerente. A implementação está baseada no protocolo SNMP (Simple Network Management Protocol) para a gerência e são considerados preponderantemente os padrões para controle de consumo dos equipamentos Advanced Power Management, APM, e Advanced Configuration and Power Interface Specification, ACPI. Além da arquitetura do gerente e dos agentes, foi definida também uma MIB (Management Information Base) para controle de consumo. No projeto do sistema, foi privilegiado o objetivo de utilização em qualquer ambiente de rede, sem preferência por equipamentos de algum fabricante específico ou por arquitetura de hardware. Tecnologias de domínio público foram utilizadas, quando possível. No futuro este sistema pode fazer parte da distribuição de sistemas operacionais, incorporando controle de consumo às redes. No texto é feita uma comparação entre os softwares existentes para controle de consumo, são apresentados os recursos de controle de consumo disponíveis nos equipamentos de computação, seguido da descrição do protocolo de gerência utilizado. Em seguida, é apresentada a proposta detalhada do sistema de controle e descrita da implementação do protótipo.
58

Posicionamento de réplicas em sistemas distribuídos

Zampieri, André January 2001 (has links)
Replicação de objetos é usada para garantir uma maior disponibilidade de recursos em um sistema distribuído. Porém, com a replicação, surgem problemas como o controle da consistência das réplicas e onde estas réplicas devem estar posicionadas. A consistência é garantida por um protocolo de consistência de réplicas. Para facilitar a implementação dos protocolos de controle de réplicas, pode-se utilizar mecanismos de comunicação de grupo como suporte para a replicação. Outro problema importante que surge com a replicação é o posicionamento das réplicas. A carga de processamento em um sistema distribuído muda continuamente e num determinado instante pode ser necessário mudar a distribuição atual das réplicas pela adição de novas réplicas, remoção de réplicas desnecessárias ou pela mudança de posicionamento das réplicas. Um sistema de gerenciamento de réplicas pode realizar esta tarefa. Este trabalho apresenta o sistema RPM – Replica Placement Manager – responsável por fornecer ao serviço de gerenciamento de réplicas uma lista ordenada de nodos potencialmente ideais, num determinado momento do processamento, para receber uma réplica de um objeto. Esta lista é criada pelo RPM, considerando um pequeno conjunto de variáveis estáticas e dinâmicas, facilmente obtidas nos nodos do sistema distribuído.
59

Utilização de Multicast na Disseminação de Escritas em Ambientes Replicados

Hofsetz, Berenice Fuchs January 1999 (has links)
Este trabalho trata da utilização de protocolos de comunicação de grupo para a disseminação de escritas em arquivos replicados. A replicação de arquivos tem como objetivo aumentar a disponibilidade dos dados mesmo mediante a ocorrência de alguma falha. Existem duas abordagens principais para a replicação de arquivos: a da cópia primária e das cópias ativas. Em ambas as abordagens é necessário que seja mantida a integridade dos dados replicados, de forma que todos cópias dos arquivos replicados estejam no mesmo estado. Essa integridade pode ser mantida pela escolha correta de uma estratégia de disseminação de escritas. Como os servidores que mantém cópias do mesmo arquivo formam um grupo de replicação, a disseminação de escritas pode ser feita através de comunicação de grupos. Neste trabalho são apresentados os sistemas de comunicação de grupo xAMp, da Universidade de Lisboa; Totem, Universidade da Califórnia; Transis da Universidade de Hebréia de Jerusalém; Horus, da Universidade de Cornell e Newtop da Universidade de Newcastle. Todos os sistemas descritos possuem características de comunicação de grupo e membership que permitem a sua utilização na disseminação de escritas para arquivos replicados. Este trabalho descreve, também, o protótipo PDERM (Protótipo para a Disseminação de Escritas em arquivos Replicados, através de Multicast), implementado para analisar o comportamento de um sistema de comunicação de grupo, o xAMp, na disseminação de escritas em arquivos replicados pela estratégia da cópia primária. Foi analisado o aspecto da manutenção da integridade das réplicas mesmo na ocorrência de falha do servidor primário.
60

Validação do mecanismo de tolerância a falhas do SGBD InterBase através de injeção de falhas

Rodegheri, Paulo Ricardo January 2002 (has links)
O presente trabalho explora a aplicação de técnicas de injeção de falhas, que simulam falhas transientes de hardware, para validar o mecanismo de detecção e de recuperação de erros, medir os tempos de indisponibilidade do banco de dados após a ocorrência de uma falha que tenha provocado um FUDVK. Adicionalmente, avalia e valida a ferramenta de injeção de falhas FIDe, utilizada nos experimentos, através de um conjunto significativo de testes de injeção de falhas no ambiente do SGBD. A plataforma experimental consiste de um computador Intel Pentium 550 MHz com 128 MB RAM, do sistema operacional Linux Conectiva kernel versão 2.2.13. O sistema alvo das injeções de falhas é o SGBD centralizado InterBase versão 4.0. As aplicações para a carga de trabalho foram escritas em VFULSWV SQL e executadas dentro de uma sessão chamada LVTO. Para a injeção de falhas foram utilizadas três técnicas distintas: 1) o comando NLOO do sistema operacional; 2) UHVHW geral no equipamento; 3) a ferramenta de injeção de falhas FIDe, desenvolvida no grupo de injeção de falhas do PPGC da UFRGS. Inicialmente são introduzidos e reforçados os conceitos básicos sobre o tema, que serão utilizados no decorrer do trabalho e são necessários para a compreensão deste estudo. Em seguida é apresentada a ferramenta de injeção de falhas Xception e são também analisados alguns experimentos que utilizam ferramentas de injeção de falhas em bancos de dados. Concluída a revisão bibliográfica é apresentada a ferramenta de injeção de falhas – o FIDe, o modelo de falhas adotado, a forma de abordagem, a plataforma de hardware e software, a metodologia e as técnicas utilizadas, a forma de condução dos experimentos realizados e os resultados obtidos com cada uma das técnicas. No total foram realizados 3625 testes de injeções de falhas. Com a primeira técnica foram realizadas 350 execuções, com a segunda técnica foram realizadas 75 execuções e com a terceira técnica 3200 execuções, em 80 testes diferentes. O modelo de falhas proposto para este trabalho refere-se a falhas de crash baseadas em corrupção de memória e registradores, parada de CPU, aborto de transações ou reset geral. Os experimentos foram divididos em três técnicas distintas, visando a maior cobertura possível de erros, e apresentam resultados bastante diferenciados. Os experimentos com o comando NLOO praticamente não afetaram o ambiente do banco de dados. Pequeno número de injeção de falhas com o FIDe afetaram significativamente a dependabilidade do SGBD e os experimentos com a técnica de UHVHW geral foram os que mais comprometeram a dependabilidade do SGBD.

Page generated in 0.0473 seconds